[personal profile] mjg59
The Register covered a story on a UEFI-based attack on Windows 8. It's actually covering this technical writeup, which is a discussion of a proof of concept implementation of an attack on the Windows 8 kernel from the firmware environment. The first approach they describe is pretty straightforward, in that they simply patch the Windows bootloader directly. Since this is what's reading the kernel off disk and launching it, patching that code means you can modify the kernel in-place and run it with built-in privilege elevation exploits.

The second approach is a little more interesting, and is based on their observation that the UEFI ExitBootServices() function is called after the kernel is loaded but before it's executed. UEFI calls are simply function pointers, so if you can run code in the firmware environment it's trivial to simply replace the function pointer with one to code of your own which does whatever you want before calling the original code. This makes it pretty straightforward to add a hook that gets run when ExitBootServices() is called, finds the kernel, patches it and then continues on its way. Since the kernel is patched after it's been read, this gets around any kind of signature checking that the bootloader might carry out.

But both these cases have something in common: they rely on the ability to run arbitrary code in the firmware environment, and that's precisely the thing that UEFI Secure Boot prevents. A system with a correct implementation of Secure Boot isn't vulnerable to the described attacks, but it's fairly unsurprising that running UEFI without Secure Boot is vulnerable. UEFI on its own doesn't provide any additional security. You're as vulnerable to bootkits as you are with BIOS.

So this isn't really a story about a surprising vulnerability. It's a story about someone taking the logical step of implementing a bootkit on top of UEFI, which is what everyone should have been expecting all along. Computers that are configured to run arbitrary code will run arbitrary code, and if that arbitrary code happens to modify your kernel so your credit card details are automatically posted to pastebin, well, that's a plausible outcome.

Not, not surprising at all...

Date: 2012-09-22 08:46 am (UTC)
tcpip: (Default)
From: [personal profile] tcpip

But FSF hand waiving makes this irrelevant

Date: 2012-09-25 04:02 am (UTC)
From: (Anonymous)
I love how this particular entry garners almost no comments. It's contrary real world evidence for people committed to believing Secure Boot is Restricted Boot, and merely a Microsoft ploy to destroy... everything,

And note the end of the article where a UEFI bootkit targeting Mac OS X was developed just before this one.

Crickets can be heard chirping.

In theory...

Date: 2012-10-07 07:43 pm (UTC)
From: (Anonymous)
Secure can be helpful in preventing bootkits. However, it can also be just as easily used to restrict booting as well. Who controls the keys controls the boot process.

Secure is just a tool. The question is who gets to wield it, the end user or just some company?


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at Google. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Expand Cut Tags

No cut tags