Recent Features
| |||||||||||||
Taking it seriouslyTaking it seriouslyPosted Jun 1, 2012 21:37 UTC (Fri) by nybble41 (subscriber, #55106)In reply to: Taking it seriously by gmaxwell Parent article: Implementing UEFI Secure Boot in Fedora
> 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.
(Log in to post comments)
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
|
|||||||||||||