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."
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.
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.
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.
> 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.
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.
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.
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?
> 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.
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?
> 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.
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.
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?
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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!"
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)?
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:
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.
[+] [-] fencepost|9 years ago|reply
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
[+] [-] devy|9 years ago|reply
[+] [-] yuhong|9 years ago|reply
[+] [-] jsjohns2|9 years ago|reply
[0] https://support.lenovo.com/us/en/solutions/LEN-8324
[+] [-] kuschku|9 years ago|reply
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
[+] [-] cdubzzz|9 years ago|reply
> 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
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
> 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
[+] [-] bsilvereagle|9 years ago|reply
> 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
> 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
[+] [-] sctb|9 years ago|reply
[+] [-] excelangue|9 years ago|reply
[+] [-] quotemstr|9 years ago|reply
[+] [-] dandelion_lover|9 years ago|reply
[+] [-] yuhong|9 years ago|reply
[+] [-] jMyles|9 years ago|reply
[+] [-] acd|9 years ago|reply
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.
[+] [-] flurpitude|9 years ago|reply
[+] [-] gvb|9 years ago|reply
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
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
[+] [-] jkldotio|9 years ago|reply
[+] [-] esaym|9 years ago|reply
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.
[+] [-] dandelion_lover|9 years ago|reply
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/
[+] [-] ff10|9 years ago|reply
[+] [-] jonwachob91|9 years ago|reply
[+] [-] mdip|9 years ago|reply
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
[+] [-] skykooler|9 years ago|reply
[+] [-] shmel|9 years ago|reply
[+] [-] kriro|9 years ago|reply
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
[+] [-] loeg|9 years ago|reply
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:
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] hoodoof|9 years ago|reply
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] unknown|9 years ago|reply
[deleted]
[+] [-] rikkus|9 years ago|reply
[+] [-] shimon|9 years ago|reply
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
[+] [-] frankosaurus|9 years ago|reply