Practical security for 2014 [LWN.net]

Practical security for 2014

Posted Jan 14, 2014 16:28 UTC (Tue) by mjg59 (subscriber, #23239)
In reply to: Practical security for 2014 by paulj
Parent article: Practical security for 2014

"Just for the record, this claim for SecureBoot is patently incorrect. Any exploit of incorrectly handled persistent state (e.g. config or other policy files, hardware database files) will remain persistent, as discussed before."

Nonsense, because Secure Boot ensures that we have a mechanism to perform updates of the affected components without having to parse that persistent data with vulnerable software.

to post comments

Practical security for 2014

Posted Jan 14, 2014 16:42 UTC (Tue) by paulj (subscriber, #341) [Link] (23 responses)

Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?

Even for known exploits, SecureBoot need not protect against it, because (for the umpteenth time), the binary that gets booted is but *part* of the input that determines the state of computation. The other parts are the non-code state, which is often modifiable, and is always key to any exploit.

E.g., it is quite plausible a kernel could have a bug that allows it to be subverted by reading a modified filesystem (to pick one kind of state kernels tend to have to parse), such as the one that the system resides on. Now riddle me this, where is your secure system to run your update code from?

Then there is the hypervisor attack, if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor? I know you dismiss this as leading to user-detectable slowness but not everyone believes that (not all systems have local users, and someone here has already mentioned knowledge of in-the-wild hypervisor attacks).

Practical security for 2014

Posted Jan 14, 2014 16:44 UTC (Tue) by paulj (subscriber, #341) [Link] (11 responses)

(the answer to the riddle is, of course, that you have to boot from alternative, known good media with a fixed kernel - just like before, despite SecureBoot).

Practical security for 2014

Posted Jan 16, 2014 14:27 UTC (Thu) by pjones (subscriber, #31722) [Link] (10 responses)

The part you've missed is that it's possible to create a persistent exploit across *reinstalls* without Secure Boot. In that case, known good media will not help you. With Secure Boot it will.

Practical security for 2014

Posted Jan 16, 2014 14:34 UTC (Thu) by paulj (subscriber, #341) [Link] (9 responses)

What type of exploit would persist across a reinstall without SecureBoot, yet not with?

Practical security for 2014

Posted Jan 16, 2014 17:42 UTC (Thu) by pjones (subscriber, #31722) [Link] (8 responses)

So the basic principle is that a rootkit installs itself as the bootloader and replaces the firmware interfaces with its own copies. Those interfaces would appear to be the same as the original ones, except they'd hide the "bootkit" from you, and present what appears to be a pristine machine to do an installation on.

It really isn't /that/ much code on a UEFI machine. You have to replace GetVariable(), SetVariable(), and GetNextVariableName() with wrappers that hide your boot entries, and you have to wrap the BlockIo driver (i.e. the block device driver in UEFI) that the EFI System Partition is being read with, so as to hide the real boot device your exploit is booting off of. The harder part is hiding it from the OS, but that's still entirely possible, since you can intercept the OS as it is loaded.

This sort of thing isn't new any more; with relatively low levels of sophistication these kinds of "bootkits" already exist. Secure Boot stops this attack.

Practical security for 2014

Posted Jan 16, 2014 17:52 UTC (Thu) by paulj (subscriber, #341) [Link] (7 responses)

Why would a reinstall not reinstall the bootloader, or at least verify what it is? That's only a part-reinstall, and yes, of course, that would leave the system vulnerable - agreed.

Practical security for 2014

Posted Jan 16, 2014 18:06 UTC (Thu) by pjones (subscriber, #31722) [Link] (5 responses)

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.

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.

Practical security for 2014

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

I think you have far more faith in a compromised machine than what the SecureBoot people do.

Practical security for 2014

Posted Jan 14, 2014 16:48 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (10 responses)

"Sure, if you know about the exploit. Are you claiming SecureBoot provides us with omniscience?"

No, but in general actively exploited vulnerabilities get noticed.

"Now riddle me this, where is your secure system to run your update code from?"

It boots a kernel that doesn't have that bug. Really, this isn't difficult.

"if your system was subverted before, how can code within it *ever again* reliably detect between running on metal and running in a hypervisor?"

How did you get the bootloader to launch an unsigned hypervisor?

Practical security for 2014

Posted Jan 14, 2014 16:56 UTC (Tue) by paulj (subscriber, #341) [Link] (9 responses)

And how do you reliably install that fixed kernel from code running within a subverted system?

Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?

Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?

Practical security for 2014

Posted Jan 14, 2014 17:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (8 responses)

"And how do you reliably install that fixed kernel from code running within a subverted system?"

The bootloader downloads and boots a fixed kernel. The bootloader is signed, so subverting the bootloader is difficult.

"Are you saying end-users will be banned from running their own hypervisors under SecureBoot? Are hyper-visors going to go the way of kexec?"

No, I'm saying that trivial hypervisors such as Blue Pill won't run under Secure Boot. Migrating a running system to something like KVM or Hyper-V is impractical.

"Also, if a kernel has a boot-time subvertable bug, how do you stop an attacker loading a hypervisor with that subversion?"

You don't, which is why your security upgrade mechanism shouldn't use that kernel.

Practical security for 2014

Posted Jan 14, 2014 17:25 UTC (Tue) by paulj (subscriber, #341) [Link] (5 responses)

Aha, so the bootloader has to do the updating now? Is that possible today with any Linux distro?

So now we need bootloaders with support for at least HTTP. It'll also need to store state somewhere for at least some basic config for network and distro parameters. At least some of those parameters will need to be validated somehow.The bootloader has to have what will likely be the exact same filesystem code (the bootloader-system-update may well be a special Linux system).

This isn't really getting any simpler, is it? :)

(This reminds me of Suns' "WANBoot", which was a bit of a beast last time I tangled with it.).

Practical security for 2014

Posted Jan 14, 2014 17:38 UTC (Tue) by mjg59 (subscriber, #23239) [Link] (4 responses)

"Is that possible today with any Linux distro?"

Currently? No. But it's possible, which it wouldn't be without Secure Boot.

"So now we need bootloaders with support for at least HTTP."

Which we already have.

"It'll also need to store state somewhere for at least some basic config for network and distro parameters."

In most cases that's going to just be built into the bootloader, but it could be overridden via EFI variables.

"The bootloader has to have what will likely be the exact same filesystem code"

The bootloader doesn't need to touch any filesystems for this.

"This isn't really getting any simpler, is it? :)"

Yes, it is.

Practical security for 2014

Posted Jan 14, 2014 17:51 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

You think network boot isn't possible without SecureBoot? (Fairly sure some systems have jumper write-protectable CMOS for boot order btw).

How are you going to protect the state in those EFI variables btw?

(I mentioned Solaris WANboot before, and securing it was a major PITA, AFAIR).

Practical security for 2014

Posted Jan 14, 2014 18:12 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

Network boot is possible without Secure Boot, but you'd need infrastructure to support that network boot (which most consumers won't have) and you'd need a mechanism to ensure that system configuration can't be modified (I've never seen a system that had hardware protection for CMOS - there's no trivial way to implement that in most cases).

Boot-services EFI variables can't be modified at runtime.

Practical security for 2014

Posted Jan 14, 2014 17:52 UTC (Tue) by paulj (subscriber, #341) [Link] (1 responses)

Why does the bootloader not need to touch the filesystem? I thought the point was to update the system on filesystem?

Practical security for 2014

Posted Jan 14, 2014 18:09 UTC (Tue) by mjg59 (subscriber, #23239) [Link]

You wouldn't do the actual update from the bootloader, the bootloader would simply be the trusted mechanism for obtaining a known-good kernel and initramfs for performing the actual update.

Practical security for 2014

Posted Jan 17, 2014 23:52 UTC (Fri) by Jandar (subscriber, #85683) [Link] (1 responses)

> Migrating a running system to something like KVM or Hyper-V is impractical.

The hypervisor jailhouse does such a migration from a running system as described in LWN.

Practical security for 2014

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

If you're migrating the running kernel as well as the running OS, it's not a problem.