Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 16, 2014 18:06 UTC (Thu) by pjones (subscriber, #31722)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

The whole point is that when it reinstalls the boot loader and sets a new boot order, it's telling the "bootkit" code the new boot order, rather than the real system firmware. The bootkit code is then able to persist in the boot path in front of the newly installed OS.

to post comments

Practical security for 2014

Posted Jan 16, 2014 19:01 UTC (Thu) by paulj (subscriber, #341) [Link] (4 responses)

Ah, I see. That stems then from a choice made to have UEFI services remain resident and overrideable, it seems. SecureBoot could make that secure, or you could avoid relying on code in the system, mutable by prior boots (as was my point ;) ).

Practical security for 2014

Posted Jan 16, 2014 20:13 UTC (Thu) by raven667 (subscriber, #5198) [Link] (3 responses)

That particular method of causing a rootkit to persist is not unique to uEFI and is has been done with BIOS for some time now. The next version of that kind of exploit is probably going to be centered around device firmware (running on the device, not device driver uEFI modules running on the CPU) rather than modifying the uEFI firmware, if uEFI firmware becomes difficult to modify remotely.

Practical security for 2014

Posted Jan 16, 2014 22:35 UTC (Thu) by paulj (subscriber, #341) [Link] (2 responses)

If I understand pjones correctly, the persistent attack in the UEFI services override case is from a disk-loaded bootloader.

In the BIOS case, at least for a long time, the BIOS EPROM was hardware write-protectable (I suspect the motivation there was more for board makers to minimise returns due to kiddies needlessly updating it than security), and the BIOS could be set to run directly from the ROM. Not bad protection. Booting from alternative media couldn't be bypassed by a bootloader on disk with a write-protected BIOS EPROM.

Without write-protection of the firmware, you're hosed, I completely agree! :)

I agree SecureBoot can give you sufficient write-protection. However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

(To make this easy, the BIOS blobs often had a well-defined structure, and it was possible to unpack them and add your own code in - the old Award BIOS certainly did. Then there was some kind of PC convention to allow option ROMs to be recognised via some magic number, and entry points automatically get called. I forget the details, but I did this once to stuff PXE-capable etherboot code for my for my option-ROM-less NIC into my BIOS as an option ROM, so I could still get a network boot ;). This kind of firmware hacking is now disallowed with SecureBoot, isn't it?).

Practical security for 2014

Posted Jan 17, 2014 16:30 UTC (Fri) by raven667 (subscriber, #5198) [Link] (1 responses)

> I agree SecureBoot can give you sufficient write-protection.

Then I'm not sure what we've been talking about because it seems like you agree.

> However, I dislike that it won't necessarily be me who says what can be written. I prefer a write-protect system that can't possibly be under anything but my control.

SecureBoot is under control of the person at the console, it can be disabled or have keys added or removed. I think for the purposes of our discussion the fact that some vendors produce boot locked hardware (Apple IOS devices, MS WinRT and WinPhone, many Android, Tivo, etc.) just doesn't exist in our universe because that's not a general purpose computer and isn't running Fedora or whatever. The fact that SecureBoot is more like the Chromebook model, where you can run a factory-signed image, or you can take control and run whatever you want, however you want, except in the SecureBoot model, we can continue to use the security infrastructure to provide integrity checks on boot.

Practical security for 2014

Posted Jan 17, 2014 16:47 UTC (Fri) by paulj (subscriber, #341) [Link]

Initially I did not agree SecureBoot provided the same security as booting from alternative, good media because I had never heard of this network-boot check thing which Matt described in the comments that it is still to be implemented. The article covering Matt's talk doesn't mention it, so I guess it wasn't a widely known issue (?). Once that's implemented I agree it potentially could provide the same guarantees. However, it's also possible there'll be practical issues that might affect that. We'll have to see.

As SecureBoot distro implementations stand today though, they're do not stop all persistent attacks.