[personal profile] mjg59
This 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)

what about DRTM?

Date: 2011-11-17 06:49 pm (UTC)
From: (Anonymous)
You seem to be describing Static Root for Trust Measurement (SRTM) where each part of the boot sequence verifies the integrity of the next phase. Afaik if you use Dynamic Root for Trust Measurement (DRTM) then a bug in a boot loader is not enough to compromise the system. Qubes development blog has somewhat related posts


You might also want to read the description of the x86 SENTER/SINIT (secure init) instruction.

Re: what about DRTM?

Date: 2011-11-18 07:52 am (UTC)
From: (Anonymous)
Does Linux do this IOMMU stuff?? If not it really should. Fucking binary-only non-free blobs.


Matthew Garrett

About Matthew

Power management, mobile and firmware developer on Linux. Security developer at CoreOS. Member of the Linux Foundation Technical Advisory Board and the Free Software Foundation board of directors. Ex-biologist. @mjg59 on Twitter. Content here should not be interpreted as the opinion of my employer.

Page Summary

Expand Cut Tags

No cut tags