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

Garrett: Secure Boot and Restricted Boot

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

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? :)

to post comments

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.