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

Practical security for 2014

Practical security for 2014

Posted Jan 18, 2014 20:43 UTC (Sat) by nix (subscriber, #2304)
In reply to: Practical security for 2014 by mjg59
Parent article: Practical security for 2014

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?


(Log in to post comments)

Practical security for 2014

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

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]

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]

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]

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]

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]

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]

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//.


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