Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 16, 2014 18:55 UTC (Thu) by mjg59 (subscriber, #23239)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

Again, Existing hardware Secure Boot provides all the infrastructure required to implement this functionality. Existing hardware does not provide the infrastructure required to implement secure boot from read-only media. If you can't see the difference between these two situations then there's really no point discussing it.

Practical security for 2014

Posted Jan 17, 2014 16:48 UTC (Fri) by nix (subscriber, #2304) [Link] (12 responses)

Existing hardware does not provide the infrastructure required to implement secure boot from read-only media.

Thus neatly explaining why the livecd of the distro I tried to install in the post above UEFI-booted without a secure boot error, unlike everything UEFI-booted off the hard drive. Another irregularity exposed to end users but not documented anywhere they can see (not until this post of Matthew's, anyway).

Practical security for 2014

Posted Jan 17, 2014 17:01 UTC (Fri) by mjg59 (subscriber, #23239) [Link] (11 responses)

Er. I think you've misunderstood what I said there. Secure Boot works fine from read-only media, but existing hardware provides no way for you to implement equivalent security using read-only media and no UEFI Secure Boot.

Practical security for 2014

Posted Jan 18, 2014 20:43 UTC (Sat) by nix (subscriber, #2304) [Link] (10 responses)

Ah. I did misunderstand. You're right that you can't ensure that your BIOS hasn't been reflashed by hostile parties without something like secure boot, but I'm somewhat unclear how secure boot can fix that, given that it's the BIOS that *implements* secure boot in the first place... surely a hostile BIOS can claim to be doing signature verification, and then, well, just not do it?

Practical security for 2014

Posted Jan 18, 2014 21:24 UTC (Sat) by paulj (subscriber, #341) [Link] (2 responses)

Many PC boards had electrically secure write-protect jumpers in EEPROM days. That's pretty damn secure. Indeed, I might have more faith in that than software signature schemes, depending on the scenario.

Practical security for 2014

Posted Jan 18, 2014 21:48 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Oh, and how is UEFI firmware in flash is protected for updates? The trust anchor in SecureBoot is established by the firmware, right (not in the CPU)?

Practical security for 2014

Posted Jan 18, 2014 22:05 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

The firmware verifies the update before flashing it. The SPI controller prevents the OS from writing to the flash.

Practical security for 2014

Posted Jan 18, 2014 21:39 UTC (Sat) by raven667 (subscriber, #5198) [Link] (1 responses)

Yes, absolutely, if someone intercepts your hardware and flashes a bogus UEFI that pretends, they could even add keys to SecureBoot to trust their bogus bootloader but that requires physical access and can't be done remotely by malware because the UEFI firmware will check the signature of any updates before applying them, a core feature of SecureBoot.

Practical security for 2014

Posted Jan 18, 2014 21:50 UTC (Sat) by paulj (subscriber, #341) [Link]

You're assuming the UEFI firmware, the reference implementation for which contains a fair amount of non-trivial C code, is free of exploitable defects.

Practical security for 2014

Posted Jan 18, 2014 22:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (4 responses)

It has nothing to do with modifying the BIOS. You can install a known good kernel on piece of read-only media and use that to boot the OS installed on your hard drive. I, as an attacker, can install an evil kernel and bootloader on your hard drive and then rewrite the CMOS settings to instruct your system to boot from the hard drive instead of the read-only media. The BIOS is entirely intact, it's just doing what it was told to do.

Practical security for 2014

Posted Jan 18, 2014 22:06 UTC (Sat) by paulj (subscriber, #341) [Link] (3 responses)

BTW, I've been trying to find which PC BIOS standard/convention required the BIOS boot-order config be in a known location in the NVRAM. Do you know where I can find that?

Practical security for 2014

Posted Jan 18, 2014 23:01 UTC (Sat) by mjg59 (subscriber, #23239) [Link] (2 responses)

It's not in a fixed location, but there's a small number of firmware vendors and they tend to leave things in the same place over product releases. You can pull the firmware vendor out of DMI so it's trivial to automate it.

Practical security for 2014

Posted Jan 18, 2014 23:18 UTC (Sat) by paulj (subscriber, #341) [Link] (1 responses)

Yeah. Digging more, it seems the RTC and some of the slots immediately after it are "well-known", and the rest vary with BIOS vendor (and even the revision of BIOS). This seems one of the more comprehensive summaries:

http://oopweb.com/Assembly/Documents/InterList/Volume/CMO...

I've been trying to work out what the other half was for, the SRAM, and as far as I can work it seems that was used for ESCD and ISA PNPBIOS stuff.

Practical security for 2014

Posted Jan 18, 2014 23:19 UTC (Sat) by paulj (subscriber, #341) [Link]

err, s/ISA//.