top | item 12036869

ThinkPwn: System Management Mode arbitrary code execution

338 points| edmorley | 9 years ago |github.com | reply

144 comments

order
[+] fencepost|9 years ago|reply
Don't just plaster Lenovo with this - they're getting the splatter because Cr4sh has been researching their firmware, but this is a multi-vendor issue.

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."

[+] CaptSpify|9 years ago|reply
Although you are correct, I don't feel it's bad to blame the vendor who was running code that they didn't know the source of, nor the reasoning behind it's existence.
[+] devy|9 years ago|reply
Perhaps financial compensation was indeed not Cr4sh's motivation for this zero day, but I felt it's a stretch to call this disclosure responsible. Also his name-calling (ThinkPwn) campaign was inappropriate and premature when the root cause was later discovered in Intel's reference code and propagated to IBVs's products.
[+] yuhong|9 years ago|reply
My personal favorite is the UEFI variable bugs that brick laptops. I think many of them are trivial to exploit even under Windows.
[+] jsjohns2|9 years ago|reply
Quite the hilarious "security advisory" [0] that Lenovo put out. They manage to take zero responsibility, shift blame to the researcher/IBV/Intel, and admit that they ship SMM code of both unknown author and purpose.

[0] https://support.lenovo.com/us/en/solutions/LEN-8324

[+] kuschku|9 years ago|reply
> and admit that they ship code of both unknown author and purpose.

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.

[+] 0xmohit|9 years ago|reply
Lenovo is soon likely to add a disclaimer:

  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.
[+] cdubzzz|9 years ago|reply
Interesting bit form Lenovo's security advisory on the matter[0]:

> 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.

[0] https://support.lenovo.com/us/en/solutions/LEN-8324

[+] geocar|9 years ago|reply
Clear as mud.

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?

[+] jkot|9 years ago|reply
Maybe author did not want to deal with Lenovo.

> 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.

[+] mindslight|9 years ago|reply
It appears that the only security being broken is that of manufacturers against owners of machines. Why should a security researcher feel the least bit obligated to collaborate?
[+] bsilvereagle|9 years ago|reply
> Vulnerable code of SystemSmmRuntimeRt UEFI driver was copy-pasted by Lenovo from Intel reference code for 8-series chipsets.

> 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.

[+] pwnna|9 years ago|reply
As confirmed by Lenovo as well:

> 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.

https://support.lenovo.com/ca/en/solutions/LEN-8324

[+] peterwwillis|9 years ago|reply
Could a mod please retitle to "ThinkPwn: Intel 8-series firmware exploit affects multiple vendors" ? It's a bit of a mouthful but reflects that this is more widespread than just ThinkPads.
[+] sctb|9 years ago|reply
Thanks, we've updated the submission title to reflect this.
[+] excelangue|9 years ago|reply
Starting with the X230 series of ThinkPads, Lenovo has used flash write protection to prevent "unauthorized" BIOS modifications. Owners of X220 laptops and below are able to reflash the BIOS to remove Lenovo's whitelist of WLAN/WWAN cards; the X230 models are currently stuck with Wi-Fi N and Gobi 3000 3G-only cards due to Lenovo's whitelist. Would this exploit allow ThinkPad owners to reflash their BIOS chip without desoldering and flashing with external hardware?
[+] quotemstr|9 years ago|reply
I wish we could even purchase machines without SMM, Intel Management Engine, and similar features. On any machine I own, I want the CPU and the software running in ring zero to be the last word on what happens. I don't think it's unreasonable to ask for a system that meets this requirement.
[+] yuhong|9 years ago|reply
I think you were there during the Win8 period when UEFI secure boot and ACPI BGRT was introduced for example, right?
[+] jMyles|9 years ago|reply
Seriously. We need a group to examine and certify on this basis. This is getting out of hand.
[+] acd|9 years ago|reply
Joanna Rutkowska has written about Intel based products that are possibly vulnerable to the Intel management engine code. Even if you run an open source operating system such as Linux or FreeBSD, there is still proprietary code in the management engine that you cannot look or verify that its secure.

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.

[+] gvb|9 years ago|reply
This should be good news for people looking to getting rid of Computrace, effectively a rootkit, from surplus Thinkpads.

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.

[+] throwaway7767|9 years ago|reply
AFAIK all the ThinkPads have a BIOS option to disable CompuTrace. Mine has three options: "Enabled", "Disabled" (default option) and "Permanently disabled".

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).

[+] yuhong|9 years ago|reply
I dislike the arms race against laptop theft. It is not as much talked about as encryption backdoors, but...
[+] jkldotio|9 years ago|reply
What are we up to now? Three preloaded spyware scandals, possible remote execution via the Intel stack and now this vulnerability. That's just what we know about, who knows what else exists. I don't think I can buy another one, which is sad as I think it was a timeless and great design.
[+] esaym|9 years ago|reply
I plan on using my quad core T520 for probably another 5+ years. All of their laptops after the T520 series have the full size keyboard with numberpad which off-sets the center of the keyboard, so now your typing is mostly happing on the left side of the keyboard and that causes wrist strain.

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.

[+] ff10|9 years ago|reply
I own a couple of Apple notebooks. Two years ago I bought a used X201 because I needed a Linux backup (official excuse) and because I love the design (actual reason). It's completely different from Apple's approach and Richard Sapper's original draft is still visible in those machines. And it runs Ubuntu just fine with an SSD upgrade and still enough memory for all purposes I have.
[+] jonwachob91|9 years ago|reply
T450S user here. What exactly does this mean for me? I get it's a security issue, but that's about all I understood...
[+] mdip|9 years ago|reply
I've always liked the build quality of the ThinkPad series though it's been a few years since I've put my hands on one. That said, it looks like they need to spend similar attention on the software. On the flip side, though, I wonder if this solves the issue with the Yoga laptops I read about recently where the user could not disable SecureBoot in order to install the operating system of their choice.

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.

[+] happyslobro|9 years ago|reply
I'm running Ubuntu on a Yoga 2 Pro, I hadn't heard about that issue. Either the exploit is now a transparent part of the Ubuntu installer, or it doesn't affect the Yoga 2.
[+] skykooler|9 years ago|reply
Sort of like all the iPhone vulnerabilities that allowed the devices to be jailbroken.
[+] shmel|9 years ago|reply
Cool. Now Lenovo admits they have no idea whose this code is and what it is supposed to do. It sounds like a shitty excuse of junior programmer: "Hey man, not my fault! I have just copy-pasted that snippet from StackOverflow!"
[+] kriro|9 years ago|reply
So this is traceable to the Intel reference implementation. I am going to assume incompetence but let's say I would assume malice instead (some government agent wrote the reference spec full well knowing it's exploitable with or without the knowledge of Intel) how would one go about soft-proving that?

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)?

[+] OneTwoFree|9 years ago|reply
I thought I have an intermediate level C knowledge, but I have no idea what is happening in the vulnerable line:

    *(v3 + 0x8)(*(VOID **)v3, &dword_AD002290, CommunicationBuffer + 0x18);
As I understand it is (was) an example code from Intel. Example codes should be easy to understand and well documented.
[+] loeg|9 years ago|reply
It's C generated by disassembling x86 assembler code. It is not an example code from Intel.

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;
    }
[+] hoodoof|9 years ago|reply
OK so what can be done to prevent this being an issue on my machine?
[+] rikkus|9 years ago|reply
Really hope Lenovo respond soon. Feel like I should leave my ThinkPads hibernated for now.
[+] shimon|9 years ago|reply
I think this exploit requires local administrative access. If an attacker already has this, you're pretty screwed to begin with.

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.

[+] excalibur|9 years ago|reply
It looks like the issue is far more widespread than just Lenovo, we just aren't aware of the full scope yet.
[+] frankosaurus|9 years ago|reply
Similar situation here... I just purchased a refurbished L420 which arrives today. Hopefully they re-flash the firmware as a matter of course.