The current state of boot security

[mjg59]

I gave a presentation at 32C3 this week. One of the things I said was "If any of you are doing seriously confidential work on Apple laptops, stop. For the love of god, please stop." I didn't really have time to go into the details of that at the time, but right now I'm sitting on a plane with a ridiculous sinus headache and the pseudoephedrine hasn't kicked in yet so here we go.

The basic premise of my presentation was that it's very difficult to determine whether your system is in a trustworthy state before you start typing your secrets (such as your disk decryption passphrase) into it. If it's easy for an attacker to modify your system such that it's not trustworthy at the point where you type in a password, it's easy for an attacker to obtain your password. So, if you actually care about your disk encryption being resistant to anybody who can get temporary physical possession of your laptop, you care about it being difficult for someone to compromise your early boot process without you noticing.

There's two approaches to this. The first is UEFI Secure Boot. If you cryptographically verify each component of the boot process, it's not possible for a user to compromise the boot process. The second is a measured boot. If you measure each component of the boot process into the TPM, and if you use these measurements to control access to a secret that allows the laptop to prove that it's trustworthy (such as Joanna Rutkowska's Anti Evil Maid or my variant on the theme), an attacker can compromise the boot process but you'll know that they've done so before you start typing.

So, how do current operating systems stack up here?

Windows: Supports UEFI Secure Boot in a meaningful way. Supports measured boot, but provides no mechanism for the system to attest that it hasn't been compromised. Good, but not perfect.

Linux: Supports UEFI Secure Boot[1], but doesn't verify signatures on the initrd[2]. This means that attacks such as Evil Abigail are still possible. Measured boot isn't in a good state, but it's possible to incorporate with a bunch of manual work. Vulnerable out of the box, but can be configured to be better than Windows.

Apple: Ha. Snare talked about attacking the Apple boot process in 2012 - basically everything he described then is still possible. Apple recently hired the people behind Legbacore, so there's hope - but right now all shipping Apple hardware has no firmware support for UEFI Secure Boot and no TPM. This makes it impossible to provide any kind of boot attestation, and there's no real way you can verify that your system hasn't been compromised.

Now, to be fair, there's attacks that even Windows and properly configured Linux will still be vulnerable to. Firmware defects that permit modification of System Management Mode code can still be used to circumvent these protections, and the Management Engine is in a position to just do whatever it wants and fuck all of you. But that's really not an excuse to just ignore everything else. Improving the current state of boot security makes it more difficult for adversaries to compromise a system, and if we ever do get to the point of systems which aren't running any hidden proprietary code we'll still need this functionality. It's worth doing, and it's worth doing now.

[1] Well, except Ubuntu's signed bootloader will happily boot unsigned kernels which kind of defeats the entire point of the exercise
[2] Initrds are built on the local machine, so we can't just ship signed images

Comments

[(Anonymous)]

If you have an IOMMU (VT-d), you can use that to protect against the ME, by not giving the ME device access to memory it shouldn't. Of course, you can only do that once you have control, and the ME has control before you do, but it does help a bit.

Wrong

[(Anonymous)]

Wrong, IOMMU can't protect against ME. Look at Intel UMA and ITL researches.

Re: Wrong

[(Anonymous)]

Last real research on ME by ITL was in 2009 where PC x86 architecture was based on 3 chips: CPU, MCH and ICH. Since then this evolved to 2 chips only: CPU + PCH.

Anyway i still did not see any real research demonstrating that ME can bypass IOMMU protection on this 2 chips CPU/PCH architecture. Only speculation and conspiracy theories.

Re: Wrong

[(Anonymous)]

It's not speculation. Tell me what IOMMU group the ME belongs to. Protip: none, because the entire system need not even be aware that it exists. The IOMMU is set up by the CPU, and the CPU cannot see the ME. And no, the Management Engine Interface is not the ME itself, so isolating it (which is entirely possible) does not provide any protection from the ME.

Re: Wrong

[(Anonymous)]

The PCI device attached to the mei_me driver -- which is the kernel module that controls AMT -- is in iommu group 4 on my Skylake X1 Carbon.

[(Anonymous)]

Apple machines did have a TPM and its usage was discussed in painstaking detail in the original OS X Internals book. Of course, everyone flipped their kids because "OMG EVIL DRM" so Apple removed the hardware.

[(Anonymous)]

And rightfully so. TPM is evil on many different levels. UEFI Secure Boot is the way to go.

[(Anonymous)]

And where do you think those keys are stored?

[mjg59]

Not in a TPM.

[(Anonymous)]

How exactly is TPM evil? It's like a cheap HSM. It even has a HWRNG built in! Sure, it's not perfect, and there are ways to bypass its protections, but it's certainly better than nothing.

[(Anonymous)]

Over the last year a community has been building a Linux based TPM measured boot virtual environment for the desktop called OpenXT. One difficulty the OpenXT community has with TPM measured boot is the transition from the 1.2 to 2.0 standard. One problem is there are very few TSS Linux implementations for TPM 2.0, making it difficult for Linux developers to incorporate this technology in their applications, including OpenXT. Trousers support for TPM 2.0 is nonexistent and Ken Goldman's implementation is beta. I can't see how Linux will support trusted measured boot without further development in making tools available.

Date: 2016-01-01 03:15 pm (UTC)

[(Anonymous)]

Matthew has a very firm handle on the principle of the boot virtual environment . I too agree with Matthew as I cannot for the life of me see how Linux will support trusted measured boot without development of making tools available.

Secure nonsense

[(Anonymous)]

Windows 8 and 10 support code injection from UEFI during boot. Lenovo used this method to distribute crapware. You cannot do a clean install on these machines and have your Windows copy remain clean.

This feature makes $ecure Boot a bad joke.

We need open source firmware and hardware. Until then security is a fairy tale.

Re: Secure nonsense

[snuxoll.id.fedoraproject.org]

The Windows Platform Binary Table is implemented as an ACPI table, it has absolutely nothing to do with UEFI and can just as easily be implemented on a system that uses BIOS to boot.

atomic initrds

[(Anonymous)]

Fedora Cloud Atomic, initramfs are built server-side, are no-hostonly, and therefore could be signed. These are a bit more than double the size of hostonly initramfs. Which is easier, setting up verifiable initrds for non-atomic installations? Or eliminating initrd boots?

How to properly configure Linux?

[(Anonymous)]

Please explain or post a link to an explanation on how to properly configure Linux, THANK YOU!

I don't understand the threat model around boot security

[glyf]

OS X, Linux, and Windows all have the ability for a privileged user to introduce arbitrary steps into the boot process once the operating system has loaded - launchd plists, systemd units, services. So anybody with write access to your root disk or firmware can do arbitrary evil on a fully boot-verified system, regardless of whether they write to EFI or not.

The security model on Apple hardware seems to be "put an EFI password on your system if you are doing anything seriously confidential on it". Evil maids are thus defended against because the OS has locked the ability to write arbitrary files to the filesystem or firmware, which are roughly equivalent as far as I can tell. Cold booting the system doesn't give you the ability to write arbitrary files to the firmware or boot volume, because the EFI password prevents you from changing the boot volume and the FDE password prevents you from changing the boot volume. So where's the attack that Apple hardware enables and others don't? I don't get it.

Re: I don't understand the threat model around boot security

[mjg59]

Circumventing the EFI password once you've got physical access is pretty straightforward, and the fact that you've got no measurement capabilities means that the victim won't notice.

Re: I don't understand the threat model around boot security

[(Anonymous)]

Matthew,

As a result of your posts, I've thought a lot more about secure booting. Great talks on youtube. Thanks.

Like many others, I'm surprised you call out Apple computers for being an untrustworthy platform. Since I use on an apple laptop, I did some research and found that newer macs EFI password can't be reset by changing ram or resetting PVRAM [1]. Is there some other way of getting around the EFI password, that I don't know about?

-Chad

[1] https://www.cnet.com/news/efi-firmware-protection-locks-down-newer-macs/

Re: I don't understand the threat model around boot security

[mjg59]

Disassemble the machine, hook to the SPI flash, rewrite the secure variable block with 0s, put everything back together and the password is gone.

Re: I don't understand the threat model around boot security

[damerell]

My understanding may be limited, but I think the attacker can't do that (put something nasty into /etc/inittab or whatever) because I supply a passphrase for my encrypted filesystem at boot time. Hence, they have to nobble a bit of the system that's before that and capture the passphrase when I type it.

Related TPM and UEFI Secure Boot 32C3 presentations

[(Anonymous)]

See this 32c3 presentation where TPM is mentioned:
"ruedi: Microsofts Windows 10 Botnet": https://www.youtube.com/watch?v=imXZqr5t89g

Also another 32c3 related presentation:
"Joanna Rutkowska: Towards (reasonably) trustworthy x86 laptops": https://www.youtube.com/watch?v=rcwngbUrZNg

Re: Related TPM and UEFI Secure Boot 32C3 presentations

[(Anonymous)]

Please use media.ccc.de and not youtube. One is tracking you and the other is the real source of the "Truth" :-)

"Ubuntu's signed bootloader will happily boot unsigned kernels which kind of defeats the entire..."

[lersek]

Assuming this boot loader was signed by Microsoft's signing service, why doesn't Microsoft release a dbx update that blacklists that loader?

Re: "Ubuntu's signed bootloader will happily boot unsigned kernels which kind of defeats the entire.

[(Anonymous)]

Bad optics.

"MICROSOFT KILLS LINUX WITH EVIL DRM" -- Slashdot, the post

Re: The current state of boot security

[(Anonymous)]

I also did gave a presentation on this topic at Navaja Negra Conference 2015 in Spain (http://n0wblog.blogspot.com.es/2015/10/insecure-booting-linux-english.html).

What I did is similar to what EvilAbigail does but my work is less automated (and more painful but illustrative at the same time :p).

It turns out that is ridiculously easy to mess with initrd and run code to capture LUKS credentials or dropping a shell.

What i do wonder is, what happens if you have grub full disk encryption (including /boot) and SecureBoot enabled? Are you still vulnerable to initrd tampering?

Regards,
Angel Suarez-B. (n0w)

[(Anonymous)]

I've spent the last couple of weeks trying to get a reasonably trustworthy laptop linux build going but it's a struggle. I got tboot working which validates both vmlinuz and initrd, but that only works on CPUs with TXT and it seems most of my machines don't have it. I moved over to coreos grub, removed all the secure boot keys and replaced them with my own. In legacy boot mode, everything works fine and vmlinuz, initrd and command line args are extended into PCRs. I switched over to EFI mode, signed grubx64.efi and can boot the kernel with linux /vmlinuz... but it's not validating the kernel signature (never mind initrd). I put the linuxefi module into the grub-mkimage produced grubx64.efi and I get a crash with a double free when trying to load the kernel with linuxefi. Has anyone got all this working with secure boot enabled and perhaps has the full steps documented somewhere? Also, what do I do about initrd, since it isn't signed? I can compile it in to the kernel, but that's going to be a bit of a pain if I make changes. I see mentions of "verity" in coreos-grub, but haven't tracked down what this is used for yet. Is there a way to validate initrd before running any code in it? Thanks!

libreboot?

[(Anonymous)]

I'm using a thinkpad t400, it's one of those lucky computers where libreboot is aviable. With libreboot and debian installed, there should be no propietary software running on this machine (except things like hdd firmware, but afaik theres no way to avoid that). I configured the included grub payload to check the kernel's pgp signed signature before booting, and set a grub password so that an attacker hopefully can't turn this off. As grub is stored inside the flash chip together with libreboot, and this is set to read only, the only possibility here is to disassemble the whole laptop, flash a infected libreboot version which no longer checks the signature and logs the encryption password. Are i am right or are there other possibilities to circumvent this? Imho this libreboot setup should be one of the most secure boot setups one can have, especially because it's 100% foss..