Garrett: Secure Boot and Restricted Boot [LWN.net]

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:44 UTC (Tue) by raven667 (subscriber, #5198)
In reply to: Garrett: Secure Boot and Restricted Boot by paulj
Parent article: Garrett: Secure Boot and Restricted Boot

> You can't patch a compromised system back to non-compromised status. The rootkit can just lie to you that it has installed the update. It can lie to you about the kernel version in boots there-after.

It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel. If you can push update code into the verified part of the boot process, from the systemd recovery console maybe, then you might be able to update before the malware could even block it. You can certainly do that for the UEFI firmware itself which has a network stack and drivers that are available before your system could be re-exploited by malware.

Of course, as I mentioned in the other thread, an exploit through unvalidated data reads such as configs, variables or filesystem mounts could subvert your checking before it gets off the ground but that's true regardless of the security precautions, your SELinux or file permissions aren't much good after malicious code is running around in the kernel.

> What you /really/ want is a "Secure Layer" between the software you don't trust (i.e. pretty much all software), and the software you have no choice but to trust (i.e. the base OS, which is on your side, but is too large and has to do too much low-level, fiddly work to be securable). Secure Boot doesn't give you that layer. The claimed security benefits are illusory.

I think that's called a hypervisor 8-) Virtualizing x86 and using the extra layer of memory protection built into modern CPU/IOMMUs has a much lower vulnerability surface area than the userspace/kernelspace and has shown to be strong in practice given the low number of VM exploits compared to the number of kernel exploits. The fact that Secure Boot isn't a hypervisor doesn't detract or affect what it does try to do.

to post comments

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 18:55 UTC (Tue) by dlang (guest, #313) [Link] (10 responses)

> It can fail to install the update but not hide that fact, it can't modify the boot procedure so you'd still be visibly booting the old kernel.

Sure it could

the label that is shown to the user has no connection with the binary blob that gets loaded, it's only convention that keeps them matching.

Once the system boots the old kernel and loads the exploit, it can then lie about what version it is.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 19:08 UTC (Tue) by raven667 (subscriber, #5198) [Link] (9 responses)

I was thinking more about the message which are printed as the kernel boots up, the first of which is the version information.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:00 UTC (Tue) by paulj (subscriber, #341) [Link] (8 responses)

The messages which modern distros have hidden away behind user friendly splash screens?

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:03 UTC (Tue) by paulj (subscriber, #341) [Link] (4 responses)

Oh, and under the control of the subverted software :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:34 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

Yes, the messages are generally hidden behind splash screens but are still accessible (the display office is in a filing cabinet in a disused lavatory in the basement with a sign on the door "Beware of Leopard" 8-) Aside from the possibility of an exploit of the firmware or kernel from stored config or filesystem metadata the kernel can't be subverted at the time those messages are printed. A syslog which sends the logs remotely or which signs them so the can't be removed/modified on disk, like rsyslog or the systemd journal, could also prevent the malware from being hidden even if it tries to retroactively edit the dmesg buffer after the malware starts, presuming that the system software is started before the malware is allowed to.

The world is not a perfect place but it seems you still have more and better options with boot time validation than without any. Heck, the threat of failing a validation check should keep most malware away of the difficult to exploit protected parts and focused on the easier unprotected parts later in the boot process where it is simpler to deal with.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:52 UTC (Tue) by paulj (subscriber, #341) [Link] (2 responses)

You're assuming syslog gets to run before the system is re-subverted, alternatively, you're assuming syslog isn't subvertable through anything it reads. I'll grant those assumptions, while not rock-solid, aren't terribly far-fetched.

You still have a *massive* assumption: that the new kernel isn't subvertable.

While, perhaps, the subversion that compromised your box on the previous boot may be fixed, that doesn't mean there aren't still a number of other extant holes still unpatched, that only the exploit writers know about.

You're assuming the exploit has only laid 1 trap to ensnare the next boot.

Back to syslog: How many remotely syslog? Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:15 UTC (Tue) by raven667 (subscriber, #5198) [Link] (1 responses)

> You still have a *massive* assumption: that the new kernel isn't subvertable.

I don't think that is assumed, I'd have had to make the claim that any and all kernel images are perfect and totally secure for you to make that claim, I didn't and that's not a reasonable claim.

> Of those, how many would notice a discrepancy between the remotely logged version numbers and the local uname -a? Hell, how many would notice if the exploit didn't bother faking the version? :)

Damn few, but once exploits in the wild start using that technique it becomes burned, some people will start putting automated checks in their logging systems and the technique will stop working. You see that happen with exploits, once they start circulating in the wild the vendor patches the vulnerability and it becomes less and less effective so that the cycle starts anew.

Garrett: Secure Boot and Restricted Boot

Posted Apr 10, 2013 6:29 UTC (Wed) by paulj (subscriber, #341) [Link]

Still though, you're putting your faith in a security technology whose effectiveness depends on an arms race where the "bad" guys are routinely way ahead. We simply do not know how to make software secure, and so there's no way we can make a large base OS secure. You're *will* regularly lose, if/when you're attacked.

To have any hope of winning the arms race, your faith must go into software that both a) is minimal in size b) is minimal in the services it presents to software that uses it c) and limits the scope of software using it. Userspace sand-boxing and VMs basically. The Android user-space is the state-of-the-art in the real-world, widely-deployed system space when it comes to security and isolation of code, I think. And note that that security model does NOT rely on "Secure Boot".

That's not OS hypervisors, note, because if you're simply running the same OS in the hypervisor you still have the same problem in your virtualised OS. You have a more secure OS underneath to do integrity checks from, I'd agree, but it does not give you any means to have any additional trust in the software you're using at runtime. You still are just as prone to runtime subversion because you still have no isolation/sandboxing between the code & data you don't trust and the rest of the software. Also, things like the Qemu hardware emulation (which seem to be used a lot elsewhere) can have relatively complex interfaces, and they weren't necessarily written in a "security first" way. There have been a number of exploits in this code over the years.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:22 UTC (Tue) by apoelstra (subscriber, #75205) [Link] (2 responses)

The messages which modern distros have hidden away behind user friendly splash screens?

Right now, without secure boot, it wouldn't help anything to display version information on boot because running 'uname -a' on the booted system would have the same effect. In a secure boot world if you've got a way to display a version and cryptographically prove that it is not a lie, it would be used.

Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:40 UTC (Tue) by paulj (subscriber, #341) [Link]

The uname -a version info the user might query would, by then, be with the kernel subverted again during (early?) boot.

Kernel info pre-boot, or kernel init might be harder to change with Secure Boot, but that doesn't get shown anymore by default. Fedora doesn't even mention version info in the default bootloader UI anymore.

Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 21:25 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

> Probably there would be a magic key (escape or F1 or something) to make the pretty boot screen go away. In fact, I think this is the case now.

Escape will toggle Plymouth. Since it's on a TTY, pretty much any arrow or function key will generate '^[', so they all work :P .