Ubuntu details its UEFI secure boot plans

Posted Mar 24, 2015 15:54 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Ubuntu details its UEFI secure boot plans by paulj
Parent article: Ubuntu details its UEFI secure boot plans

> Further, at least some of the point of SecureBoot seems to be to give MS (or more likely partners) a false sense of security that the copy of Windows that is booted is the code that MS shipped.

It doesn't actually do that, it's completely misdesigned if that were the case, it's intended to stop the boot process if the low level boot code has been trojaned so that you can boot into a recovery partition and wipe away the trojan without requiring a support call or a trip to the computer shop to have a technician do it for you. Ideally you can get an anti-malware system started early to clean out the higher level OS components which have a greater attack surface area. SecureBoot doesn't provide any reliable way to attest whether the OS has been booted correctly, aside from the fact that the OS booted at all, unlike TPM which tries to measure the running state to see if anything has been changed.

Ubuntu details its UEFI secure boot plans

Posted Mar 24, 2015 17:19 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Well, a low-level attack, e.g. VM/BluePill attack: Indeed, SecureBoot can't stop that because, as you describe, SecureBoot doesn't have a secure anchor to attest the running state. The VM can simply emulate SecureBoot.

What others involved in the Linux side of SecureBoot have said is that it is there to prevent persistent exploits. This is for a narrow definition of machine. E.g. on Fedora UEFI validates the SB shim's signature. The SB Shim validates the Fedora signature on the kernel. The kernel validates signatures on any modules are loaded.

In theory they could go further and also have the kernel validate signatures of ELF objects, at least for certain classes of ELF objects (by user, by SELinux label, whatever).

That's quite a chain of software that can be verified as "Secure", from bootloader to modules (already) and potentially even to (select) user-space binaries - no technical barrier. I don't know the details of the Windows solution, but I gather they also have signed drivers that are checked, so I assume they have a similar chain of trust.

Now, this chain of trust is still rooted in a firmware that can't be validated by the OS, but that's hard. The chain on Linux includes a good bit of software which almost certainly has a multitude of unknown security bugs.

So, I don't know quite know what you mean by “It doesn't actually do that, it's completely misdesigned if that were the case, it's intended to stop the boot process if the low level boot code has been trojaned”.

From what I can tell, SecureBoot *is* being used to validate (to an extent) that kernel and driver code is signed with a trusted key - certainly on Linux, and I thought somewhat on Windows too. So it is being used to try validate that the booted code (inc OS) is the vendor shipped code.

I also agree SecureBoot doesn't do much to actually prevent or detect after boot whether or not the OS actually:

a) Is the code that was meant to be booted

b) Has not been subverted.

Even assuming the firmware itself was not exploited. Yet, this seems to be the hope some have for SecureBoot. Also, I think just measuring the code is insufficient. It ignores the other, essential, part of computing: The state. And exploits often originate in the state!

Either we're actually in agreement or one of us is confused. ;)

Ubuntu details its UEFI secure boot plans

Posted Mar 26, 2015 15:00 UTC (Thu) by raven667 (subscriber, #5198) [Link]

> Now, this chain of trust is still rooted in a firmware that can't be validated by the OS, but that's hard.

Sure, that's why they didn't go down that road, SecureBoot is narrowly scoped so as to be easier to implement and less disruptive. There already exists the TPM for trying to validate a running system.

> VM/BluePill attack

SecureBoot doesn't attempt to stop people from running VMs, that would be silly, but that is the problem people worry about with kexec or grub if malware can _transparently_ rewrite the whole boot process using signed tools (bootloader, kernel, userspace) in a way that doesn't require user intervention and that the end user and anti-malware software can't trivially detect. It's no problem if no one actually builds widely deployed malware that uses this tactic, but if it starts get widely used to deploy malware then you would probably want to revoke the bootloader at the top of that chain, but that may not be possible, as we've seen in an analogous instance with X.509 CAs who have poor validation practices, sometimes they are too much trouble to revoke.

If the signed grub or whatever didn't have a way to boot arbitrary things without user intervention, even if it just had some forced wait in a menu/splash screen or required an interactive OK before booting something arbitrary so that it would be obvious it was there, that might be enough to make it unattractive for malware.

> Either we're actually in agreement or one of us is confused. ;)

As a co-worker always says, "blame me, it scales well".

Ubuntu details its UEFI secure boot plans

Posted Mar 25, 2015 22:54 UTC (Wed) by mathstuf (subscriber, #69389) [Link]

> unlike TPM which tries to measure the running state to see if anything has been changed.

I thought TPM was the reverse problem: does the software trust the hardware?