Attacks on secure boot
Nov. 17th, 2011 11:42 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
mjg59This is interesting. It's obviously lacking in details yet, but it does highlight one weakness of secure boot. The security for secure boot is all rooted in the firmware - there's no external measurement to validate that everything functioned as expected. That means that if you can cause any trusted component to execute arbitrary code then you've won. So, what reads arbitrary user data? The most obvious components are any driver that binds to user-controlled hardware, any filesystem driver that reads user-provided filesystems and any signed bootloader that reads user-configured data. A USB drive could potentially trigger a bug in the USB stack and run arbitrary code. A malformed FAT filesystem could potentially trigger a bug in the FAT driver and run arbitrary code. A malformed bootloader configuration file or kernel could potentially trigger a bug in the bootloader and run arbitrary code. It may even be possible to find bugs in the PE-COFF binary loader. And once you have the ability to run arbitrary code, you can replace all the EFI entry points and convince the OS that everything is fine anyway.
None of this should be surprising. Secure boot is predicated upon the firmware only executing trusted material until the OS handoff. If you can sidestep that restriction then the entire chain of trust falls down. We're talking about a large body of code that was written without the assumption that it would have to be resistant to sustained attack, and which has now been put in a context where people are actively trying to break it. Bugs are pretty inevitable. I'd expect a lot of work to be done on firmware implementations between now and Windows 8 ship date.
(Update: It's probably worth pointing out that although Ars talk about it defeating secure boot, the primary sources don't seem to mention secure boot at all. Windows 8 will boot without secure boot, so it's possible that this attack merely handles the non-secure boot case)
(Further update: It turns out to be a purely BIOS based attack. In other words, it's an example of the kind of thing that secure boot is intended to prevent, not any kind of compromise of a secure boot implementation)
None of this should be surprising. Secure boot is predicated upon the firmware only executing trusted material until the OS handoff. If you can sidestep that restriction then the entire chain of trust falls down. We're talking about a large body of code that was written without the assumption that it would have to be resistant to sustained attack, and which has now been put in a context where people are actively trying to break it. Bugs are pretty inevitable. I'd expect a lot of work to be done on firmware implementations between now and Windows 8 ship date.
(Update: It's probably worth pointing out that although Ars talk about it defeating secure boot, the primary sources don't seem to mention secure boot at all. Windows 8 will boot without secure boot, so it's possible that this attack merely handles the non-secure boot case)
(Further update: It turns out to be a purely BIOS based attack. In other words, it's an example of the kind of thing that secure boot is intended to prevent, not any kind of compromise of a secure boot implementation)
what about DRTM?
Date: 2011-11-17 06:49 pm (UTC)http://theinvisiblethings.blogspot.com/2010/04/remotely-attacking-network-cards-or-why.html
http://theinvisiblethings.blogspot.com/2009/01/why-do-i-miss-microsoft-bitlocker.html
You might also want to read the description of the x86 SENTER/SINIT (secure init) instruction.
Re: what about DRTM?
Date: 2011-11-17 06:57 pm (UTC)Re: what about DRTM?
Date: 2011-11-18 07:52 am (UTC)