Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 10, 2014 8:16 UTC (Fri) by ibukanov (subscriber, #3942)
Parent article: Practical security for 2014

> Chromebooks have the same problem; the software can be replaced, but not in a secure mode.

At least Samsung ARM Chromebook allows to replace the firmware and get a custom verified boot, but doing that is non-trivial, http://krblogs.com/post/63809988096/bootloader-unlock-on-...

Of cause, it would be nice if Google would allow to add an extra signing key to the stock firmware similar to what Microsoft requires, but that is a double-sword. There are attacks when users are tricked to install an extra root certificate in the browser as a a part of "enabling advanced gaming features". I would not be surprised that with a user-friendly key adding the same attack can be used to add a custom enabling persistent malware kernel.

to post comments

Practical security for 2014

Posted Jan 10, 2014 8:20 UTC (Fri) by Cyberax (✭ supporter ✭, #52523) [Link] (6 responses)

The way forward would be asking Google to counter-sign user certificates. Perhaps, limiting them to a single machine.

Practical security for 2014

Posted Jan 10, 2014 10:58 UTC (Fri) by ibukanov (subscriber, #3942) [Link] (5 responses)

How Google can do that signing? It cannot be done via a website, as malware can just submit the key via that web interface.

Practical security for 2014

Posted Jan 10, 2014 16:26 UTC (Fri) by raven667 (subscriber, #5198) [Link]

That's true as far as it goes but as a practical matter a hypothetical key-signing web interface could use CAPTCHAs, verification over email or SMS, require password re-auth to make sure that the owner is in the loop. The central authority also has privileged access to the request logs and can mine them to block the signatures of scripted attacks. So there is not a 100% guarantee of no signed malware but the risk can be mitigated in several ways.

Practical security for 2014

Posted Jan 13, 2014 14:53 UTC (Mon) by epa (subscriber, #39769) [Link] (3 responses)

Each Chromebook would come with a piece of paper listing a secret code you need to type into the web interface for Google to sign your bootloader. Or even a sticker on the bottom of the computer - the point is it's not something which can be read by software.

Practical security for 2014

Posted Jan 13, 2014 18:23 UTC (Mon) by khim (subscriber, #9252) [Link] (2 responses)

This will not work. Said code would need to be kept in some separate database to make sure warranty is properly voided when bootloader is unlocked. But if don't mind voided warranty then you can already remove washer so what's the point?

Practical security for 2014

Posted Jan 17, 2014 9:49 UTC (Fri) by robbe (guest, #16131) [Link] (1 responses)

Isn't Matthew's criticism that removing the washer does away with Secure Boot altogether (i.e. it removes any precieved security)?

Practical security for 2014

Posted Jan 17, 2014 13:28 UTC (Fri) by mjg59 (subscriber, #23239) [Link]

Removing the washer allows you to reflash your own keys. You then need to replace the washer in order to re-enable security, otherwise anyone who gains root can replace your keys.

Practical security for 2014

Posted Jan 10, 2014 11:28 UTC (Fri) by ssmith32 (subscriber, #72404) [Link] (5 responses)

I don't think you can update the signing keys for UEFI secure boot via the browser.. all instances I've heard of require a user to be physically present at the console on the boot of the machine. This is about as user-friendly as it's ever going to get.

I'm not sure what browser certificates you're talking about - but it sounds like root CA certs for SSL.. which is not really the same thing (but definitely an issue)..

Take care,
-stu

Practical security for 2014

Posted Jan 11, 2014 4:30 UTC (Sat) by drag (guest, #31333) [Link] (4 responses)

I don't see anything less then requiring to move a jumper to make a portion of a flash drive read-write should be required.

Making this sort of thing update-able from a browser pretty much completely defeats the purpose of having secure boot in the first place.

Practical security for 2014

Posted Jan 11, 2014 4:34 UTC (Sat) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

> I don't see anything less then requiring to move a jumper to make a portion of a flash drive read-write should be required.

In most cases it's usually a keypress immediately after the cold reboot. That's not as resilient as a jumper, but still pretty secure.

Practical security for 2014

Posted Jan 11, 2014 4:53 UTC (Sat) by drag (guest, #31333) [Link] (2 responses)

Just as long as it can't be done via software is really the most important part.

But nothing beats physically disabling the ability of the computer to write to flash when it comes to making sure that nothing writes to flash without your permission. :)

Practical security for 2014

Posted Jan 11, 2014 5:17 UTC (Sat) by tnoo (subscriber, #20427) [Link] (1 responses)

Sure, as long as the flash drive or the system's software really honors this jumper setting. Like, for example, CHDK on Canon cameras uses the storage card lock slider to indicate whether the firmware should be loaded from the card on bootup. If so, the camera writes the images to the locked storage card.

The situation might be still worse with flash drives which contain full microcontrollers doing all kinds of elaborate calculations, and thus are likely to be hackable as well.

Practical security for 2014

Posted Jan 17, 2014 10:05 UTC (Fri) by robbe (guest, #16131) [Link]

> The situation might be still worse with flash drives which contain full
> microcontrollers [...]

Every storage device since at least 2000 (including "simple" cards) includes controllers sufficiently complex to host malware.

See for example http://www.bunniestudios.com/blog/?p=3554