|
|
Subscribe / Log in / New account

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 5, 2013 19:22 UTC (Tue) by dlang (guest, #313)
In reply to: Garrett: Don't like Secure Boot? Don't buy a Chromebook by hummassa
Parent article: Garrett: Don't like Secure Boot? Don't buy a Chromebook

if you have the system booted from known-good external media, the rootkit is not running and so it cannot alter the checksum result.


to post comments

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 5, 2013 19:30 UTC (Tue) by raven667 (subscriber, #5198) [Link] (5 responses)

And this is the kind of guarantees you want to try and enforce using secure boot, to get the same experience as booting a live CD but using the binaries already on your system, or a recovery partition on your system. The farther you can push out the point where unchecked code can run and push a rootkit into the running kernel the better. That window can be pretty short though as code can be put into the initial ramdisk and run before PID 1. It'll take many years to gather the interlocking integrity checks to push out the integrity barrier out to a point where you can have a trusted beachhead for keeping your system clean.

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 5, 2013 21:49 UTC (Tue) by hummassa (subscriber, #307) [Link] (4 responses)

It is still no guarantee at all, since the root kit kernel mode can be introduced via a carefully crafted dhcp response or USB connected device -- this last way is usually what we do to jailbreak apples.

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 5, 2013 22:12 UTC (Tue) by raven667 (subscriber, #5198) [Link] (3 responses)

That's fine, its outside the scope of secure boot which is just protecting the boot loader and early boot process, there will always be kernel exploits that this technology doesn't do anything about. Even in the scenario you describe though you can't persist the compromise, you have to re-exploit the device every time it boots and it can still be patched without the patch being trojan'd, shutting down the exploit.

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 6, 2013 0:17 UTC (Wed) by FranTaylor (guest, #80190) [Link]

So what you are saying is that you are investing millions of dollars to secure the front door while leaving the back porch open.

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 7, 2013 4:10 UTC (Thu) by paulj (subscriber, #341) [Link] (1 responses)

So the justification for SecureBoot is security, but arguments about the security of the system are out of scope in considering the case SecureBoot?

Garrett: Don't like Secure Boot? Don't buy a Chromebook

Posted Feb 7, 2013 15:18 UTC (Thu) by raven667 (subscriber, #5198) [Link]

The security of the whole system is a wide ranging topic covering application security, kernel security, etc. SecureBoot only has an effect on the UEFI firmware and bootloader code, it doesn't even extend to the kernel, and it only help prevent replacing or modifying the firmware and bootloader without the admin's permission. All other system security is out of scope. What you do with the small advantage that being able to trust the bootloader is the same bits and bytes that it's supposed to be, is up to the implementor.


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