ThinkPwn: System Management Mode arbitrary code execution
github.com
github.com
A few important notes from the article and the releaser's blog post:
* This is not a Lenovo problem so much as a problem for multiple vendors who used BIOS based on Intel's reference information. The original problem was with source code provided by Intel. The same problem is confirmed to exist in at least one HP system.
* This was apparently fixed back in 2014, but there doesn't seem to be an indication that it was recognized as a security flaw then or at least it wasn't noted as a security fix. 2014 isn't that long ago in terms of propagating BIOS updates.
* Cr4sh apparently decided to just release, "I decided to do the full disclosure because the main goal of my UEFI series articles is to share the knowledge, not to make vendors and their users happy."
* His assessment is "It’s very unlikely that this vulnerability will be exploited in the wild, for regular customers there are much more chances to be killed with the lightning strike than meet any System Management Mode exploit or malware."
I don't think there's a single OEM that knows what they're actually running – if there is, SAMSUNG would likely be it, because they have a chance at actually doing everything in-house.
Or put another way, I suggest adjusting your sensitivity before cracking open an issue of Phrack.
And a serious question: in your view what would be a "responsible" way to release a multivendor exploit? Please describe the preconditions which would need to be met before you'd use the adjective.
I had thought the complaint was about not waiting until what sounds like most of the PC OEMs stopped sitting on their thumbs. Please disregard that part of my response.
Lenovo put users at risk and public shaming is a tool to correct their behaviour.
Lenovo could allow users to replace software on their machine, but presently choose not to because they might make less money.
However if Lenovo are shamed, people might buy less of Lenovo's products, which will also make Lenovo less money.
It's probably harmless but I'm not so sure it's silly. It's much more distinguishing than monikers like "CVE-2016-0093". It can sometimes convey the seriousness of the relevant exploit (not sure if that's the case this time though). These branded-vulnerabilities are also probably much more valuable on a CV as such.
I still think it is silly.
I'm less convinced the trend has any use for communicating seriousness. I don't expect product names (basically what this is) to meaningfully convey actionable information in any trustworthy way. But I'll reconsider next time I see a car named "Cheap, mostly-OK vehicle with probable future maintenance headaches" or an exploit named "Smasher of stacks of a little-known utility optionally installed alongside Enterprise Product X, so long as these 7 unlikely preconditions are met".
That's literally what every vendor does nowadays. Do you think LG can get the code for the firmware of the SoCs they use in their phones? Do you think the coreboot guys can get the source for the Intel Management Engine firmware? Do you think any of the firmware in your system comes from your OEM and is secure?
This is a failure in the entire industry, and it's getting worse every day.
The proper solution would be simple, too: Allow everything to be flashed with custom software, but allow the user to set a cryptographic key with which updates have to be signed. By default, the system could accept the OEM key, the user could lock it further down.
Provides additional security for corporations and nerds, provides additional flexibility, provides the ability to modify the firmware.
No, of course not. But I'm surprised that Lenovo would tacitly admit this.
Back then we had Amibios, Pheonix bios etc etc, but these days we call it "UEFI" and "firmware" and everyone gets up in arms about it.
First is the FCC vs WIFI channel selection in firmware. They want the choice to interfere be removed from the user in this occasion.
Second is cell carriers are not wild about unknown basebands conversing with their networks. In theory the network should defend against bad phones but they'd rather not test that.
THERE IS NO SECURITY FOR THE HARDWARE OR SOFTWARE, TO THE EXTENT PERMITTED BY APPLICABLE LAW.
SHOULD THE HARDWARE OR SOFTWARE BE COMPROMISED, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.> Shortly after the researcher stated over social media that he would disclose a BIOS-level vulnerability in Lenovo products, Lenovo PSIRT made several unsuccessful attempts to collaborate with the researcher in advance of his publication of this information.
Lenovo has previously sacrificed user security and privacy for money (superfish), so it does not surprise me that they have done it again, and these kinds of weasel words aren't going to get me to buy another Lenovo product again.
Here's an idea: How about not putting backdoors in our products?
How about making it easier for consumers to replace software on systems they own?
Methinks you have never owned an IBM Thinkpad to make that statement.
The one I bought in 1999 broke through a cracked screen when a pencil got wedged between the frame and the screen because the hinges were not as strong as those today.
The T42, T43 and T60 series were absolutely incredible for their times but were now without fault; even back then they screen bezel was huge and you had to pay unreasonable money to get a screen with a higher resolution than 1024x800.
My Z60 was a fantastic machine that I ended up giving away. Its battery life, however, will not be missed.
My last T420 has an assembly that flexed far more than I liked and buttons whose pretty uniform black wore out with use, but I still keep it in the closet because it's indestructible. It's ugly as sin though.
I have my minor disagreements with the keyboard design of the X250, but the trackpad is great, the screens have actually usable brightness now with their default configuration, and battery life has gone way, way, way up.
Let's not look at the past with rose-colored glasses. Every one of those machines had a minor issue as far a Linux compatibility (always different), but back then it was a pain in the ass to get the WiFi working, whereas now if anything I might have a complaint about default keyboard bindings. Things change, but at no point in all that time did I have to send any of those machines for repairs (save for the Z60's fan getting clogged with dirt and some random memory module that died).
People get enamored with their machines and their particular quirks, but I much prefer the new, thinner machines. The tradeoffs are tradeoffs, and the defects are just different. Hell I even prefer the new chiclet keys over the old keys.
The only thing I can say is different is that the frame of the newer machines flexes more. That is not a defect; a frame that flexes is far more resistant to falls and impact. All of my machines have fallen off chairs at some point; all of them survived intact.
> Lenovo did not develop the vulnerable SMM code and is still in the process of determining the identity of the original author, it does not know its originally intended purpose.
> I agreed to do that, but they haven't accepted my terms and conditions (just for case -- I haven't asked them about money)
Although based on the author's original blog post and title for the GitHub repo, it seems that he originally thought it was Lenovo specific...
The tiny sliver of end-user threat - a customer's machine gets pwned with a rootkit that a reinstall cannot wipe - can and always could have been eliminated by manufacturers simply shipping proper documentation!
> Alex James found vulnerable code on motherboards from GIGABYTE (Z68-UD3H, Z77X-UD5H, Z87MX-D3H, Z97-D3H and many others):
This is beyond the scope of just Lenovo machines.
> The package of code with the SMM vulnerability was developed on top of a common code base provided to the IBV by Intel. Importantly, because Lenovo did not develop the vulnerable SMM code and is still in the process of determining the identity of the original author, it does not know its originally intended purpose. But, as part of the ongoing investigation, Lenovo is engaging all of its IBVs as well as Intel to identify or rule out any additional instances of the vulnerability's presence in the BIOS provided to Lenovo by other IBVs, as well as the original purpose of the vulnerable code.
He repurposed an old Arduino into an SPI flasher and a chip clip to sit on the bios flash chip.
The current exploit only runs far later, after the validation is performed. So unless you manage to mangle the code execution flow of the authentic firmware to the point that it skips the whitelists, you can't get rid of it.
EDIT: The obvious answer would be that they didn't have one handy and were competent enough that de- and re-soldering the chip was not a big deal.
EDIT (again): Also, they wanted to flash a NEW chip with the contents of the original so that they could fall back to the original in the event of failure.
[0] https://www.bios-mods.com/forum/Thread-TUTORIAL-Lenovo-X230-...
[1] https://www.digikey.com/product-detail/en/pomona-electronics...
Because they tried and it didn't work (third post). It seems to depend on the mobo as well as the programmer you're using, but sometimes SPI programming without removing the chip doesn't work, which has to do with the mobo consuming the power you're supplying to the chip. Some people work around that by supplying separate power but even then it's a crapshot.
ARM Chromebooks in particular I think are theoretically supposed to have fully open source firmware, though the documentation is a little sparse... probably mostly for the same reason, lack of interest.
https://blogs.oracle.com/fatbloke/entry/using_virtualbox_to_...
Like FSF [0]?
Here is the paper http://blog.invisiblethings.org/papers/2015/x86_harmful.pdf
UEFI is another gigantic hide point for malware.
I think one could possibly run more simple platforms such as Raspberry PI, Odroid which may not have embedded management engines. That should be more secure than x86 platforms.
http://forum.thinkpads.com/viewtopic.php?t=114641
Yes, I bought a surplus Thinkpad (T61) and found it had Computrace activated on it. Grrrr.
Yes, I could call the Absolute(R) Software number and they should disable it for me. I have not been willing to sit on hold and jump their hoops to date. Since I run linux on the laptop, is fairly low risk for me, but Absolute(R) Software could inadvertently or intentionally "brick" my laptop. Grrrr.
The "permanently disabled" option erases the CompuTrace blob from the flash chip, so it cannot be re-enabled afterwards.
This may not be the case for their non-business machines (i.e., not ThinkPad).
Having a numberpad is really lame on a laptop. I won't buy one and I know of no one else that likes the numberpad either.. sadly many manufactures are doing the same.
I am about to buy and advice to others the only freedom-respecting laptops [0].
[0] https://minifree.org/product/libreboot-t400/ and https://minifree.org/product/libreboot-x200/
What shipping and receiving? Somewhere between where you will receive the package -- be it your home, PO Box, postal office, etc -- and the originating storage facility (ie: warehouse), there is a long list of hands exchanging your product. One of these hands would be an NSA agent's hands.
https://en.wikipedia.org/wiki/Interdiction
Who is targeted? In all likelihood, businesses, but I'm sure individuals are targeted as well.
The attack requires physical access to the hardware.
And just to be clear -- it's not just Lenovo products. The net seems to have been cast much wider and other devices seem to be affected (HP laptops, desktop motherboards).
What it hopefully does do is cast a little ray of light on this suite of user-hostile firmware, helping us expunge this long present software muck that, for example, allows such interdiction attacks to be so easy.
It's a little sad to be excited about a vulnerability because it might provide an opportunity for a consumer open up the products they rightfully purchased.
Here's the story I was referring to:
https://globalvoices.org/2016/06/16/in-defense-of-free-softw...
And the HN thread:
Compare machines that are vulnerable in the wild and same spec machines from important people at Intel and/or suspected government agency (assuming they'd simply use a non-vulnerable version instead of some completely different hardware)?
*(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);
The function pointer at `v3 + 0x8` is invoked with arguments: (1) the pointer at `v3 + 0x0`, (2) some fixed pointer, and (3) a pointer into the CommunicationBuffer.
E.g. here's more idiomatic C code to represent the same idea:
struct Thunk {
void *argument;
void (fp)(void *, DWORD *, void *);
};
struct CommunicationBuffer {
uint64_t unknown[4];
struct Thunk *thunk;
...;
};
EFI_STATUS __fastcall sub_AD3AFA54(
EFI_HANDLE SmmImageHandle, VOID *CommunicationBuffer, UINTN *SourceSize)
{
struct CommunicationBuffer *cb = CommunicationBuffer;
if (cb->thunk) {
cb->thunk->fp(cb->thunk->argument, &dword, &cb->unknown[3]);
cb->thunk = NULL;
}
return 0;
}In other words, while this could definitely make an attack more damaging and harder to remove, it doesn't seem like a reason to stop using a computer that has decent software and physical security.
indeed countermeasure like full disk encryption, computrace and Mac firmware passwords are all examples of things we do to raise the difficulty for a physical attacker.
BTW, I have physical access.
If you can get someone to run a USB that'll boot you open the user up to a bazillion exploits already and already own the machine.
I'm assuming that would probably need admin/root access to exploit, but it does mean that you can turn an OS-level privilege escalation bug into something substantially more persistent and difficult to recover from.