Slashdot Mirror
Researchers Demo Exploits Bypassing UEFI Secure Boot
itwbennett writes "Researchers demonstrated at Black Hat this week two attacks that bypassed Secure Boot in order to install a UEFI bootkit — boot rootkit — on affected computers. The first exploit works because certain vendors do not properly protect their firmware, allowing an attacker to modify the code responsible for enforcing Secure Boot, said researcher Yuriy Bulygin, who works at McAfee. The second exploit demonstrated by the researchers can run in user mode, which means that an attacker would only need to gain code execution rights on the system by exploiting a vulnerability in a regular application like Java, Adobe Flash, Microsoft Office or others. In both cases, the exploits are possible not because of vulnerabilities in Secure Boot itself, but because of UEFI implementation errors made by platform vendors."
Of course, a hardware security system that is too complex to verify seems like a fatal flaw.
Hence why UEFI should be dismissed. If it's useless, just don't implement it, it's cheaper...
I gave up with the idea of an useful sig...
UEFI was never intended to improve security. Along with Microsoft's extensions it was designed as a lock-in tool. Too bad we had to wait until it pops up everywhere just to realize it.
Film at 11.
I do not fail; I succeed at finding out what does not work.
"Of course, a hardware security system that is too complex to verify seems like a fatal flaw."
Why is that? We cannot verify that CPUs do not have "secret knock" codes. Is that a "fatal flaw"? All it really means is that you can't be sure that your CPU isn't performing any malicious activity. The best you can do is trust that it isn't. I suppose you could spend all your time looking for such evidence, but you still wouldn't be able to prove a CPU isn't performing malicious activity in exactly the same way you cannot prove a non-trivial program is correct simply by testing it on enough inputs.
What a fool believes, he sees, no wise man has the power to reason away.
Does this mean I can't install Linux or Windows 7 on a UEFI Secure Boot machine? (Newbie here)
It depends. You usually can, in a BIOS-compatibility mode, which most offer. But those can be buggy and/or incompatible. I have a server that can't go over 2GB of RAM in the Xen Dom0 because of lack of support for the UEFI memory space, which is beyond the BIOS compatibility region apparently.
Some of the distros have gone hat-in-hand to Microsoft to get their own keys to avoid such issues. That work is leading to verifiable boots, which is a good thing, and Microsoft's spec is supposed to allow people to install their own keys, but I've read that some UEFI implementations don't do that right (more coding mistakes, I'd assume).
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
Some implementations correctly enable you to simply turn off Secure Boot but otherwise leave UEFI (and the rest of the BIOS) intact.
A method of disabling Secure Boot is required by the spec and by Microsoft. It may not be implemented well, but then, that's true of every component of the BIOS.
Being able to install your own keys is a great feature, because actually having a verifiable boot chain can be a pretty useful security tool.
Just not how it is implemented with MS as the gatekeeper with the private key.
I hate the BIOS. It is 30 years old, archaic, has weird instructions such as do not use more than 1 meg of ram, and many hacks and patches to get around the original 30 year old hacks like the 1 meg limit, etc. ACPI for a fucking decade never quite worked! Linux got blamed because companies like Dell did things a little differently with their ACPI so when the computer went to sleep sound would not work when it came up etc.
Remember the SOYO boards 10 years ago which you had to disable power management before they even booted? What about the 10 year old Dell machines which put everything in IRQ 11? Want to upgrade your video card? Nope conflicts and BSOD. OF course slashdotters blamed XP, but investigation showed the IRQ conflicts were caused by crappy ACPI.
The list goes on and on.
EFI was supposed to fix this and use firmware like everything else modern. I like the secure boot idea and wish you could change the keys so you can sign any OS with a C.A.? Just put in a jumper or a master password. I like the idea of TPM for encryption as well. UEFI was supposed to replace the archaic ancient BIOS. Not supplement it and have MS be the gatekeeper.
To me perhaps a new UEFI where these issues are addressed and intel could perhaps provide a Windows 7 driver too as many of us and corps who need Windows God forbid wont touch Windows 8 or anything else and would like these features.
Linux as a result would be less buggy if everyone played by the same standards.
http://saveie6.com/
Yes.
Besides the secure boot bit, Windows 7 is UEFI friendly. What you need to do is go into the bios or setup when you first turn it on and disable secure boot and you are good.
Man, if it were not MS being the only C.A. secure boot would be a great standard for Linux, FreeBSD, and WIndows 7.
http://saveie6.com/
so an windows 7 UEFI boot loader can come out
not right now but the black hats are working on ways to allow it so you can make that worthless Microsoft surface pro scream on Red hat
Clearly what we need here is another, lower layer of bootkit protection to protect UEFI secure boot.
(100 years later....)
"Oh no! All 6000 layers of bootkit protection have been breached!"
"Those fools! If only they'd given it 6001 layers! When will they learn!?"
"When information is power, privacy is freedom" - Jah-Wren Ryel
Do tell who made made this piece of shit.
Increases in complexity are usually increases in security vulnerabilities.
Also, boot times and installation are now longer and more complex...and just like the NSA, we are still no better in our security.
What a horrible joke.
Good luck finding new "machines which cannot run the Secure Boot feature" at an affordable price once virtually every name-brand home PC not made by Apple ships with Secure Boot turned on in Windows-only mode. The last time GNU/Linux had a reasonable chance to ship on home PCs was netbooks, and Microsoft quickly killed that by offering deeply discounted Windows XP licenses for ULCPCs.
A method of disabling Secure Boot is required by the spec and by Microsoft.
In Windows 8 (x86 and x86-64), it is required. In Windows RT, it is forbidden. And other comments to this topic speculate that Microsoft is likely to license Windows 10 like Windows RT in this respect.
If they'd included a classic shell
Microsoft did one better by providing hooks for third party developers to create classic shells for Windows 8. I know of at least two classic shells, one of which is actually called Classic Shell.
In my blog, I describe my use of BootIt Bare Metal to rapidly test installs of "semi-embedded" software I write that involve wrapping third-party installs of drivers as sub-installs. This will work only as long as BIOS's and Microsoft continue to support "legacy mode". I'm just hoping that the scientific & embedded world finishes moving to Linux before "legacy mode" disappears.
"Of course, a hardware security system that is too complex to verify seems like a fatal flaw."
Then again, who is telling us that they actually bothered to verify anything? Where exactly does this assumption come from that the system is too complex to implement?
You can write buggy and flawed software in any language, framework and system - regardless of its ease of use.
Amen
Learning HOW to think is more important than learning WHAT to think.
Then set up another CA. Microsoft isn't stopping anyone from doing it.
>Microsoft's spec is supposed to allow people to install their own keys
The Windows 8 certification requirement outright mandates that users are able to upload their own keys. (See here, "Windows 8 System Requirements", page 121, paragraph 17.)
This thankfully gives us a pretty solid standing to complain at hardware makers who don't do it right.
In the long run, I am not sure it will be necessary, though. I've been looking into those issues after getting a laptop with SecureBoot enabled, and sane options are in development. The interesting thing about UEFI is that it comes with an extensive API, and can be configured from inside the currently running OS (check out efibootmgr on Linux for instance). When the dust has settled, installing and launching Linux will probably not be so vastly different from right now. Time will tell.
-- B.
This sig does in fact not have the property it claims not to have.
Sorry, but if it's not directly built in as a user accessable option, then who cares if the hooks are there.
There is a user-accessible option to open Internet Explorer, type windows 8 classic shell into the Bing search box (which produces this SERP), and click the first result. Or is your complaint that Microsoft provides no means to discover that such a classic shell exists in the first place? If that's true, then the same is true of obscure registry settings that do exist in Windows, and it's true of the existence of web browsers other than IE.
Speaking of IE, Microsoft got in trouble with competition law for including things with Windows. I'm guessing this is why Microsoft declined to ship MSE bundled with Windows XP, Windows Vista, and Windows 7 so as not to be perceived as using its Windows market power to gain antivirus market power.
[People who bought a GNU/Linux netbook tended to be unsatisfied] because they didn't know how to use Linux. They'd buy the machine, get it home, unbox it, boot up, then suddenly ask 'What the hell is this crap?' and 'Why can't I install my software?'.
Unfamiliarity with the GUI didn't stop people from taking to the iPad. The reason has to be more subtle.
But doesn't only Microsoft have the private keys used for secureboot?
Also how do you add keys? A nightmare scenario would be where malware signs its bootkit in it making it impossible to remove!
Sun had pins with its firmware updates where by default it is set read-only and can move them to flash an update. Maybe something like this or a secure USB flash could be used and the EFI could refuse to load the keys any other way?
http://saveie6.com/
Yep. TPM really is a better design than what's in UEFI. The attack surface against UEFI is quite big.
I actually have a third exploit against part of the whole Secure Boot process, this time a Microsoft bug in Windows itself that lets me load unsigned kernel code at boot time with Secure Boot enabled.
This flaw works on all architectures, so I'm saving it for now. I found it trying to find a new jailbreak for Windows RT 8.1.
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
OF course slashdotters blamed XP, but investigation showed the IRQ conflicts were caused by crappy ACPI.
You'll no doubt be pleased to hear that UEFI still requires ACPI in all its crappy glory.
You get to pick 2 ... on a good day.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
"But doesn't only Microsoft have the private keys used for secureboot?"
Not in the sense you think it does, no. When people say this, what they mean is 'Microsoft is the only company that has decided to act as a CA for Secure Boot and ask hardware vendors to ship its keys in their firmware implementations'. Anyone else could choose to try and do this as well; no-one else has. Secure Boot per se is simply a definition of a system by which a firmware can use public key-based cryptography to validate a boot chain. It does not say anything at all about who should issue keys or which particular keys any given firmware implementation should trust.
You can get your own signing key from Verisign. It is up to each OEM to properly implement UEFI on its motherboards; the EFI and later UEFI standard and its revisions have been open and freely available from the start.
IF an OEM properly implements UEFI and the secure boot portion then you will be able to boot any OS which ships with a valid key, or use your personal signing key to vouchsafe any OS you choose. Far as I can tell the problem lies entirely with OEMs that have lazy, improper, or incompetent implementations of open specs.
Of course, even if OEMs do everything correctly there will still be plenty of end-users who'll screw up. At least that part will never change. What Descartes really said was, "I fuck up, therefore I'm human." but his editor made him change it.
OpenBoot/OpenFrimware
Yeah, it'd be nice. One problem, I think, was timing. By the time open source started becoming reputable and acceptable by business the EFI was too far along. Another, related, was the amount of effort going into OpenBoot couldn't begin to match the industry-group efforts. I think it's a shame, but too little, too late (not the work itself, but the acceptance of it as valid).
So, using coreboot should help, by preventing security by obscurity. It have a lot of benefits: open source, small size, fast boot (while UEFI just a whole operating system, though without multithreading) and so on... Also it should help prevent some security problems of proprietary UEFI/BIOSes.
"You can get your own signing key from Verisign." ...which is acting as an agent for Microsoft. That's the whole program we're talking about, that was set up by Microsoft: they will sell you the right to have your boot chain signed by a key that's signed by their key, as long as you can jump through some fairly basic 'good actor' hoops. The reason you would do this is that most SB enabled systems trust those keys, because Microsoft's OEM requirements require them to trust those keys.
The point I'm making is that there is no reason Microsoft has to be the only entity that does this; not written in the SB spec, not written in the Microsoft OEM requirements, not written anywhere. It would be entirely feasible for someone else to set up as a 'top level CA' for SB by convincing hardware vendors to trust their key, and then selling subkeys, the way Microsoft does. The fact is that nobody has done this, but there's nothing in particular preventing it.
as long as it makes it more difficult to run or install linux or *bsd or other alternative operating systems, then it has done its job.
i always thought that Restricted Boot was created to advance the interests of Microsoft and the RIAA....but it wouldn't surprise me if the NSA was behind it too.
Absolutely agreed.
As I am trying to understand it, if the OEM sets up UEFI and SB properly, I should be able to insert my own signing key, not just one that's been pre-authorized, whomever I got it from.
I hope that finding an OEM that does this right when I get my next mobo rather than just drinking Remond-flavored Kool-Aid is not going to be too much of a hassle, but I suspect otherwise.
Well, that's interesting, because at least in theory, if you want to be sure you can set up your own keys, you should actually buy a system that has the 'Redmond-flavored Kool-Aid': Microsoft's Windows 8 OEM licensing requirements actually specifically state that the firmware must allow access to SB Setup Mode, which is what you use to configure your own keys.
The UEFI / SB spec itself, IIRC, does not in fact require this - it defines and describes Setup Mode, but IIRC, doesn't actually require that the user be given access to it.
It's a bit early to tell how this is working out in practice, so far. We are, of course, dealing with firmware engineers, who write bugs into their code just for the larks, and never show up at work without a crack pipe in each hand. It's a bit hard to tell what's people being confused about the specs, what's a bug, what's typical firmware crappiness, and what if anything is an Evil Microsoft Conspiracy...
I guarantee you very shortly after UEFI was even thought about the NSA would be at their door with a mandated back door, and covered by NSL Letters! So UEFI is protection from insecure boot, except if the Gov. wants in.
That last para got a good laugh out of me, thanks!
I agree, particularly in that it seems that much will depend on what a given OEM will deliver. I am unsure exactly what the spec requires about access to setup mode; my reading of the relevant stuff on Wikipedia, openboot, and a few other places has left me confused - and I admit much of the discussion was a bit over my head to begin with.
I really dislike being in the situation that my best reaction to an impending situation is summed up with: "Aw, shit."