User: Password:
|
|
Subscribe / Log in / New account

Taking it seriously

Taking it seriously

Posted Jun 1, 2012 20:26 UTC (Fri) by nybble41 (subscriber, #55106)
In reply to: Taking it seriously by gmaxwell
Parent article: Implementing UEFI Secure Boot in Fedora

You don't really need to validate the channel over which the update is downloaded (which would essentially require validating the entire Internet). You just need to validate the signature on the update itself before applying it, which can be done with a much smaller core of verified code.

The unverified code could _block_ the update, of course, but that could happen anyway: upstream ISP blocks the connection, someone pulls the physical ethernet plug, system experiences a DoS attack, etc. If this is a problem, the secure boot code could require a new, signed update after a given number of reset cycles. The update server would need to attest that the update is current, e.g. by signing the reset count at the time the update was downloaded, signed in turn by the boot code.


(Log in to post comments)

Taking it seriously

Posted Jun 1, 2012 20:49 UTC (Fri) by gmaxwell (guest, #30048) [Link]

I'm not saying you have to validate the channel, I'm saying that you can't execute any unsigned code in order to get access to the channel. At least with our current software infrastructure in Fedora we're using millions of lines of code before we can get a system online.

Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.

Or to put it more simply— What _goal_ (not mechanism) of an attacker will SecureBoot in Fedora thwart. It's advertised on windows as preventing unremovable rootkits, but I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace or moving a lot of networking code into init/systemd.

Taking it seriously

Posted Jun 1, 2012 21:37 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> Otherwise— if unsigned code runs before updates— the unsigned code will have been modified by the attacker, it will execute a kernel exploit, and the exploit will undermine the update process— not just DOS it but make it look successful while keeping the machine compromised.

Not if the update process is sane. The unsigned code connects to the Internet, downloads the signed update, and stores it somewhere the boot code can access. You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and, if the signature is valid, applies it. The kernel never has write access to the secure boot parameters, so a kernel exploit can't undermine the update process beyond blocking the update.

To address that case, when the last valid update becomes too old the system can refuse to boot in secure mode, which should be fairly noticeable. A less drastic measure would be for the secure code to simply report the release date of the last update on startup, though that requires you to trust your display path.

Taking it seriously

Posted Jun 2, 2012 6:54 UTC (Sat) by dilinger (subscriber, #2867) [Link]

After my exploit takes over the system, I replace your unsigned code with my own. It pretends to download the secure update, but either a) doesn't, or b) just re-downloads an older (still exploitable, and very much signed/valid) update.

You then reboot into a known-good state, and the signed and validated boot code checks the signature on the update and.. whoops, there is no update (or we apply an older update if the user expects to see something happen). The system boots up, the exploit is re-run, and the user has no idea that they're still running an old version.

Taking it seriously

Posted Jun 4, 2012 4:43 UTC (Mon) by raven667 (subscriber, #5198) [Link]

I don't understand why a secured, trusted process would have a dependency on an exploitable unsecured process. That doesn't seem like a sane design

Taking it seriously

Posted Jun 2, 2012 3:48 UTC (Sat) by raven667 (subscriber, #5198) [Link]

> I've explained why it can't do that at least on Fedora/Linux without signing a substantial hunk of userspace

I think you're expecting the cart to be in front of the horse. Of course you only have a trusted code path as far as you've implemented a trusted code path. There is no point in implementing the userspace or even kernel checking until the lower layers are done because you could always hide a persistant rootkit one layer down than what you are checking. Building on the secure boot framework, now that it exists, will allow the other checks to happen, but it is not that implementation.


Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds