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.
So, literally every vendor? Can you think of a single example of a vendor not running UEFI code from others, not running either Qualcomm's kernels for ARM chips, nor distributing Intel's ME firmaware, nor distributing AMD's TPM firmware?
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.
It's only been a few days since disclosure. No PC manufacturers these days knows every single line of code they get from their vendors - if they did, there wouldn't need to outsource it in the first place.
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.
I'm much more upset with the vendors that thought UEFI was a good idea and pushed it, than security researches who discover vulnerabilities in UEFI, no matter how they choose to disclose it.
UEFI vs BIOS itself isn't the issue. UEFI, the specificaiton, is really a nice interface to the hardware. The issue is with specific implementations of UEFI, and the fact that UEFI firmware vendors (much like traditional BIOS firmware vendors) can churn out hacky code and nobody is the wiser.
Name calling? Come on. I'm not really a fan of the trend of "branding" vulnerabilities, but it is just harmless silliness, and substantially less inflammatory than security industry smack-talking norms from not too long ago.
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.
Give the vendor a timeframe to investigate and resolve. Even sometimes ignores reports like this, at least give them the courtesy instead of expose this as an 0day.
My mistake - I had developed the impression that Lenovo was informed ahead of time. I had only skimmed at first.
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.
> I'm not really a fan of the trend of "branding" vulnerabilities, but it is just harmless silliness
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.
Sure. "Silly" is in the eye of the beholder, of course, and I do think successfully executing the "launch" of an exploit is probably a great career move.
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".
Don't you need root access for those? They're awful bugs, yes, but being able to semi-permanently brick a laptop from privileged userspace isn't super surprising. If you can reflash the firmware without the firmware checking signatures on updates, you're done.
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.
That's going to get complicated for network interactions and legislative bodies. Two examples come to mind.
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.
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 has always maintained a higher standard for their Think products, Superfish was only an issue on the Idea line. Doesn't excuse the debacle, but ThinkPad's are their professional line of notebooks and they make every effort to keep a positive image.
The sale happened ten years ago and it is extremely unlikely that there are any contractual obligations for this anymore. Let's put this meme to rest; Lenovo has been building solid Thinkpads.
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.
I've been quite happy with my work-issued ThinkPad W540, it's a brick compared to my Dell XPS 13 (9333) but I would expect that considering the hardware it packs.
> 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.
The author (Dmytro Oleksiuk) tweeted [0]: 'Dear vendors, “give us your 0day vulnerability for free and don’t publish anything” — it’s not a cooperation request'.
True. The part of the statement that stands out to me is the word "collaborate", which seems to imply that they made some sort of contact (since they didn't say "unsuccessful attempts to contact") so your theory may be accurate.
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...
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?
Because when a company sells millions of things to people, those people are potentially affected. Giving the company -- even one you have no particular love for -- a chance to figure out how to mitigate risk for their customers is a nice thing you do for their customers.
In this case, there is no customer risk to be mitigated! The only thing that could be "mitigated" is the owners' newfound access to their own hardware!
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!
> 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?
My coworker replaced his BIOS/UEFI with an open source version (thinkpads enable this). It allowed him bypass Lenovo’s whitelisting of “approved” hardware, so he could install his own 3g modem.
He repurposed an old Arduino into an SPI flasher and a chip clip to sit on the bios flash chip.
Is the open source version you speak of Libreboot? That's the only open source BIOS replacement I know for any thinkpads. That Thinkpad looks a bit new for full-fledged librebooting! Did he have to reflash the ME firmware back on?
Most likely not; the flash protection is not done by the firmware, but by the Intel Management Engine and a public key burnt into silicon (Intel Boot Guard).
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.
On X220 and previous, the whitelist is removed by creating a modified version of the BIOS without the included whitelist, then flashing it to the BIOS chip. Technically, this can still be done on X230, but as it has the flash write disable unless a signed Lenovo image is to be flashed, the user must desolder the BIOS chip and flash it with the modified image using an SPI chip flasher. As this exploit can remove this flash write protection, perhaps a modified BIOS image can be flashed from the system itself, bypassing the Lenovo signature check?
Huh, here[0] is a a tutorial on removing the whitelist for the X230, via desoldering and an SPI flasher. Looking at the images, the chip looks like an SOIC-8. I wonder why they didn't just use a test clip like this one[1]...
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.
>I wonder why they didn't just use a test clip like this one
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.
Huh, interesting. I managed to do it successfully on my X201, but only after supplying power through the RasPi I was using to flash it (no power to the board, battery and clock battery disconnected, though I doubt the latter was necessary).
The Sierra cards seem to have the explicit ability to change the USB ID (this is how they signal the OS to use serial or newer packed based drivers), so I would think you could easily use a newer card with the USB ID set to one of the old ones? I have not tested this yet.
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.
An alternative is to use ARM-based devices: they typically lack microcode updates, and while TrustZone hypervisors are often present and the situation varies by device, at least some devices should allow the user to gain full control of the CPU without having to exploit anything. (I don't know how common that is, because every device manufacturer has their own boot process, and from some quick Google searching it seems like most of the time nobody bothers to figure out how the TrustZone stuff or the boot chain works, being satisfied with custom Android images...)
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.
As far as I know anything Allwinner-based lets you run whatever you like with full control of the CPU, probably the same with other Chinese ARM SoCs but there seems to be more of an open source community around Allwinner for some reason. (The other main alternative is Rockchip.)
Old, outadated, with low specs only for those who need high performance. For 90% everyday tasks these laptops are more than enough. For me specifically and for many of my friends, they are 100% enough.
Note that I mentioned how it does not do any microcode updates though. I blogged http://yuhongbao.blogspot.ca/2015/06/why-your-core-2-process... about a problem that can prevent 64-bit Win8.1 from installing. I think you were there back then too, right?
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.
Even the raspberry pi ARM cpu is slave to the VideoCore GPU, as the GPU (and its corresponding binary blob) is what initializes first on powerup and only later does it boot up the ARM CPU.
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.
Wow this was actually going to be a major buying factor in my next Laptop, was really considering a gaming laptop for the numpad but I guess it wouldn't be too difficult to buy a bluetooth numpad for the right side of the keyboard/get used to the numbers above the keyboard. Thanks for this angle. Never considered wrist strain.
Which would involve needing to reinstall the OS, or at least the kernel, because Trisquel strips out the kernel drivers needed to update the microcode.
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.
The attack against you would be interdiction, where the NSA (or whomever) would MITM shipping and receiving.
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.
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).
I'm sure the NSA has other ways of bypassing security of the proprietary firmware (likely even through the front door), so this single exploit doesn't really add to that threat.
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.
The example exploit is run from an UEFI shell which requires physical control of the device. It mentions exploitation from the OS as a possibility however one would expect that the OS shouldn't allow such operations as a non root user.
Typically physical control is deemed as the game ender. If this is proven to be OS executable it will be a major issue. Many of the Adobe, IE, and other high volume exploit vendors codebase zero-day root exploits would allow one to not only gain access at a root level on a machine, but now also at a much lower level. This level would negate the typical benefits of recovering from a root-level "hack" via HDD erasing or Malware Removal tools or any other method available to even tech-savvy people.
It very probably is (on non secure boot systems). The EFI system partition is just a FAT32 partition that can be mounted e.g. using mountvol. The EFI boot options and order are stored in changable variables (see efiboootmgr). Writing this code to ESP and setting it up to run on next boot then chainload windows doesn't sound too hard.
Sure, but there's not exactly a shortage of privilege-escalation exploits around. It doesn't seem like this is exactly a drive-by "oh please look at this resume.rtf.doc" type of attack, but it could become one with time if it goes on too long. Somebody would just need to stack things up in the right way, to get privileges in the OS and then from there inject the EFI code. That'd be a heck of a rootkit.
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:
Maybe. From the assembly we don't know what type the pointer is. The general C style for closures ("thunks") is to store two pointers—a function and `void `. Since `void ` can point to anything, it's fully general. But maybe the original has a less general type and we can't tell from the assembly.
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.
This exploit just requires physical, not administrative, access to the machine. You build an EFI "app", put it on a flash drive, and execute it from the UEFI shell.
Well, physical access ranks higher than administrative. If an attacker has physical access, no system is secure, if only because the interface to the system is no longer.
its not longer fair to call game over with physical access;
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.
The thread above is not talking about a locked down, limited-freedom device like an iPhone. Laptop computers come with the ability to boot from external devices, unlocked and unrestricted.
The readme at the linked Github repo mentions that it probably is exploitable from a running OS if you implement your own EFI_BASE_PROTOCOL.Communicate() function.
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.
Fuck 'em for sure. What can be done, will be done; taking out knobs like that wont prevent the people who would be changing that setting anyway in the long run.
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."