Garrett: Secure Boot and Restricted Boot

Posted Apr 9, 2013 20:03 UTC (Tue) by paulj (subscriber, #341)
In reply to: Garrett: Secure Boot and Restricted Boot by paulj
Parent article: Garrett: Secure Boot and Restricted Boot

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

to post comments

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.