UEFI Bootkits
Sep. 20th, 2012 01:00 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59The 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.
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)But FSF hand waiving makes this irrelevant
Date: 2012-09-25 04:02 am (UTC)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)Secure is just a tool. The question is who gets to wield it, the end user or just some company?