LWN: Comments on "LSS: Secure Boot"

updates

raven667 — Fri, 05 Oct 2012 15:28:28 +0000

The only code for which key material is in EFI is code that is run from EFI, firmware and bootloaders, which doesn't get updated very often as a practical matter. Revocations are likely to be rare. Drivers and other OS code which is more likely to have vulnerabilities and patches is handled by whatever OS specific mechanisms each OS decides on.

updates

mjg59 — Fri, 05 Oct 2012 13:59:46 +0000

It's possible to push out an update that wipes the existing blacklist and instead revokes the key at the root of that trust. That would be inconvenient (everyone with valid signed material would need to get it resigned) but possible.

updates

oak — Fri, 05 Oct 2012 10:29:03 +0000

What happens when the blacklist key database gets full?

LSS: Secure Boot

Cyberax — Tue, 25 Sep 2012 08:29:41 +0000

Naw, HSMs are protected against trivial attacks like this. I know for a fact that a certain large HSM from a company which names begins with "T" has an intermediary buffer that holds data after the encryption for a random (and quite significant) amount of time before transmitting it to client.

LSS: Secure Boot

alonz — Tue, 25 Sep 2012 08:20:24 +0000

Yeah, that sure is reassuring. </sarcasm>

Have you, perhaps, seen this? Or this (as applied to HSM's, considering the incompetence apparent from the first link)? I don't think HSM's are as magic as people expect them to be…

LSS: Secure Boot

Cyberax — Mon, 24 Sep 2012 18:24:34 +0000

Well, the world's root DNS zone is also signed by a key in a HSM.

LSS: Secure Boot

hummassa — Mon, 24 Sep 2012 09:07:01 +0000

> Now, to be fair, part of that's because vendor keys have been easier to get hold of

No, that's not "part of that". s/part of //. The security process stops at the easier way to the threat to get what he wants. Threats can and will leak keys from Microsoft (remember NT4/XP source code?) if that's the easier way of signing device drivers. As vendor keys are currently easier to get hold of, and they do the job just fine (because there are a lot of vendors and IIRC once the keys were revoked another version of Stuxnet signed with another key popped up) the threats don't need to go after MS.

Security = you don't have to outrun the beast, you have to outrun the friend beside you.

LSS: Secure Boot

nix — Mon, 24 Sep 2012 08:42:23 +0000

So... if MS's key gets compromised and a huge proportion of the world's machines are rendered unbootable... MS gets compensation? That's reassuring.

LSS: Secure Boot

nix — Mon, 24 Sep 2012 08:41:39 +0000

True enough. Still, the paranoid in me sees a billion or so eggs landing in one basket, and thinks 'this is *wrong*, this is *stupid*'.

LSS: Secure Boot

nix — Mon, 24 Sep 2012 08:41:03 +0000

Several major keys from various CAs have been compromised already: more will come. If this scheme really gets going, these keys will be a *major* target -- do you really imagine that nobody with sufficient resources to get a copy won't try? (Perhaps, if they are sufficiently clever and lucky, they might even arrange to get the *only* copy: that'd be amazingly useful to extort money from MS with, though very hard since I'm sure MS have lots of backups).

LSS: Secure Boot

raven667 — Mon, 24 Sep 2012 03:50:07 +0000

I'm sorry, are you asserting that Verisign and other major entities are leaking their root keys all the time? We're not talking about passwords for your disk encryption, we're talking about real professionally managed CAs. If some vendors signing infrastructure were compromised to sign arbitrary binaries, like the DigiNotar incident, then that subroot can be blacklisted without affecting other vendors. The root has to sign so very few things that it has very little attack surface area.

LSS: Secure Boot

Cyberax — Mon, 24 Sep 2012 01:04:22 +0000

All large companies use HSMs (Hardware Security Modules) to sign keys. They are guaranteed to be unhackable in _practice_, and that guarantee is backed by a very large sum that manufacturer would pay you in case of a breach.

LSS: Secure Boot

mjg59 — Mon, 24 Sep 2012 00:36:22 +0000

If you wanted to attack Windows in the current non-Secure Boot world, the single most valuable thing would be the ability to sign arbitrary code as a valid Windows driver. But, somehow, nobody's managed to get hold of Microsoft's key. Now, to be fair, part of that's because vendor keys have been easier to get hold of (see Stuxnet), but even so having the Microsoft key would be an advantage - if you've got the root then there's no process for revoking existing installations. And yet it hasn't been leaked.

LSS: Secure Boot

hummassa — Sun, 23 Sep 2012 22:46:05 +0000

YES, Please.

People imagining these schemes forget that crypto keys are leaked and recovered all the time IRL. And that if you are not a government, you can always use the wrench method. https://xkcd.com/538/

LSS: Secure Boot

nix — Sun, 23 Sep 2012 22:32:42 +0000

Yeah. Because they'll never make any key management mistakes, there'll be no social engineering, no industrial espionage, no simple burglary -- after all, nobody at all has any reason to want to get hold of a bit of data which could kill huge numbers of Windows boxes at a stroke, no sir.

(Remember, the attackers only have to be lucky once.)

LSS: Secure Boot

raven667 — Sun, 23 Sep 2012 21:37:58 +0000

I think you underestimate how easy defense is compared to offense when protecting keys. Any individual subroot can be revoked and replaced via a secure update, the root key hardly ever needs to be used and can be kept offline and safe against anything short of a Mission Impossible type attack.

LSS: Secure Boot

nix — Sun, 23 Sep 2012 21:21:43 +0000

But if Microsoft were penetrated and their key stolen... correction, not if: *when*.

LSS: Secure Boot

mjg59 — Sun, 23 Sep 2012 14:22:53 +0000

That doesn't help a great deal - if Microsoft have an entry in KEK then they're in a position to blacklist Linux binaries even if there's a more generic Linux key present as well.

LSS: Secure Boot

mjg59 — Sun, 23 Sep 2012 14:16:30 +0000

I don't understand what you're suggesting. Any binary can be revoked, regardless of who signed it.

LSS: Secure Boot

raven667 — Sun, 23 Sep 2012 12:05:54 +0000

I don't think there is an incentive for them to do that, the money isn't any where near good enough.

LSS: Secure Boot

ballombe — Sat, 22 Sep 2012 23:15:26 +0000

Unless Sony get its virus signed with the microsoft key.

LSS: Secure Boot

raven667 — Sat, 22 Sep 2012 22:14:25 +0000

Personally I think that this risk is a reason that the major Linux vendors such as RedHat, Ubuntu, Debian and SuSE should work together and with OEMs to make sure they have their own keys in the root of the firmware. This will cost millions of dollars and be an ongoing cost to keep the secure signing infrastructure but it provides a measure of independence. A related solution is to work with Linux-friendly VARs to make branded devices and try to get similar market share and margins as Apple does with their Mac hardware. This might be harder than Apple though because Linux will never be restricted to run on only branded boutique hardware so its revenue stream is not protected.

LSS: Secure Boot

mjg59 — Sat, 22 Sep 2012 16:05:00 +0000

> So a bug to windows update could be used to upgrade the boot loader to a vulnerable one ?

No.

LSS: Secure Boot

ballombe — Sat, 22 Sep 2012 15:55:23 +0000

So a bug to windows update could be used to upgrade the boot loader to a vulnerable one ? This increases the attack surface somewhat.

LSS: Secure Boot

nix — Fri, 21 Sep 2012 23:12:59 +0000

Well, that's OK for Microsoft because it'll presumably push out an update to its bootloader to no longer be a blacklisted one at the same time.

Shame if it decides to blacklist the Fedora key. All of a sudden every single secure-booted instance of one of its competitors that is dual-booted with Windows has stopped working! And there is, as far as I can see, no easy way to recover. (Maybe Fedora could make a boot CD image available that would update the bootloader, splash it in big letters all over fedoraproject.org, and hope that everyone affected thinks to look there. *shiver*.)

(I have 'secure boot' on this new system of mine. I have, of course, turned it off. The last thing I need is a way of rendering my system magically unbootable. I have enough of those as it is!)

LSS: Secure Boot

nix — Fri, 21 Sep 2012 23:08:38 +0000

I doubt it needs to be very convincing to convince enough people to be useful to attackers. Heck, the less convincing it is the better it may be for them -- as with Nigerian scams, it helps their marks self-select for stupidity.

LSS: Secure Boot

mjg59 — Fri, 21 Sep 2012 18:33:51 +0000

Then the signature is revoked, blacklist updates are pushed out through Windows Update and Microsoft have to press a lot of new media.

LSS: Secure Boot

raven667 — Fri, 21 Sep 2012 15:14:58 +0000

I'm sorry but that is pure BS. By what mechanism do you think this is likely? Win8 has been out for free for anyone to test for months now and I haven't seen anything even hinting at a compromise published. The boot loader is a small piece of code and auditing it is a completely tractable problem. Maybe you haven't noticed but MS has gotten religion about security in the last decade and has some of the most thorough auditing of any software project.

This is just a fancier way to make the statement "Linux rulez and MS droolz" which isn't a useful statement.

LSS: Secure Boot

ballombe — Fri, 21 Sep 2012 14:56:05 +0000

It is easily predictable that the day Windows 8 is released, the windows boot loader will be compromised to boot arbitrary code. So one get 24h of protection, then what ?

LSS: Secure Boot

raven667 — Fri, 21 Sep 2012 13:18:00 +0000

I suppose one could make it deliberately difficult to make such subterfuge difficult to be convincing by including splash screens or other visual indicators of what is going on. There is also the fact that such an attack will have to carry around a lot of code, tens of megabytes or more, making it unwieldy in many environments.

LSS: Secure Boot

mjg59 — Fri, 21 Sep 2012 05:24:59 +0000

No, if you can launch a sufficiently convincing hypervisor from within Linux then you can win. As yet I haven't seen any examples of a sufficiently convincing hypervisor, but I look forward to seeing what people come up with.

LSS: Secure Boot

raven667 — Fri, 21 Sep 2012 05:18:24 +0000

Do you know of any thing that would prevent the scenario where a compromised system modifies the boot such that you boot into a trusted boot loader and trusted kernel which then runs the original OS image as a VM and has its way with it. AFAIK Secure Boot doesn't protect a VM from its hypervisor.

LSS: Secure Boot

raven667 — Fri, 21 Sep 2012 05:13:22 +0000

> What is the threat model?

The threat model that Secure Boot is intended to help thwart is fairly simple, it makes no claims about OS security or vulnerabilities in the kernel or rootkits in the running system, it's only claim is that you can boot into the kernel without the possibility of a rootkit already having been planted in the firmware or bootloader. The rest is whatever scheme you dream up for the OS.

What people are using this tool for is to implement integrity checking in the kenrel that can't be easily and persistently subverted. It didn't make a lot of sense to invest heavily in integrity checking before when the underlying layers were so easy to subvert. Since you can't subvert any of the persistant storage without breaking the signatures then your malware has to be started using normal OS means and you can use standard OS tools and anti-malware to detect and clean it out before it runs. The anti-malware can have its own integrity checking on updates so that a compromised system can be cleaned just by rebooting it. The malware can't subvert the anti-malware but it can potentially block updates although this can be easily detected.

The concern with the security of the boot loader is that there are going to be a number of signed boot loaders from various vendors out in the wild that will all be trusted by every machine by default. If those boot loaders can be configured to run arbitrary code then any one of them could be used as a shim to load malware before the kernel and anti-malware has a chance of loading which drives a particular design where the boot loader does some sort of authorization checking as to what kernel image it is booting.

None of this protects an OS which is running in a VM from the hypervisor although it still has the same protections from malware inside the OS. As far as I know the threat model of Secure Boot can't handle the case where you Secure Boot into a legitimate bootloader and legitimate kernel which then boots the OS as a guest in a VM. It'd be an interesting proof of concept to see how one would modify a compromised running system to include booting a hypervisor without breaking the system in some way. Maybe someone who knows more than me can help answer this question, mjg59?

LSS: Secure Boot

mjg59 — Fri, 21 Sep 2012 04:49:32 +0000

So you run all your code as root?

LSS: Secure Boot

cyanit — Fri, 21 Sep 2012 04:11:51 +0000

Again, WHAT THE FUCK is the threat model?!?

As far as I can tell, you can just run Windows in a fullscreen qemu instance with full access to the hard disk, and the user will think it's the legitimate version of Windows...

Is access to Windows partitions on disk somehow blocked by the kernel?

If so, why not just have the BIOS and SATA controller cooperate to do that (i.e. irrevocably disable access to a disk range until reboot), thus allowing arbitrary software to run without issues?

Then, what's the point of having all this for Linux, when root can just add something in /etc/init.d that takes over the system silently, and any user can do the same using autostart?

Also, do you REALLY expect all Linux code (esp. in drivers) to not contain a ton of security holes exploitable by a root user, considering this was never thought to be a problem?!?

Have you spent the millions (or billions) of man hours needed to do a thorough review of the Linux code and mathematically prove that there are no holes?

Is this all just for show because otherwise Microsoft wouldn't sign the bootloader?

Because the way it is described, it provides no real security whatsoever, at all.

LSS: Secure Boot

mathstuf — Sun, 16 Sep 2012 15:45:46 +0000

> …so they're not going to object.

<pedantic>…via that argument.</pedantic> ;)

LSS: Secure Boot

mathstuf — Sun, 16 Sep 2012 15:42:02 +0000

Hmm…fun. I've been hibernating my netbook which has Intel graphics and have not seen/noticed any failures. I'll be doing a fsck next boot :) .

What everyone needs to know

CChittleborough — Sat, 15 Sep 2012 22:57:17 +0000

To understand the whole Secure-Boot-and-Linux kerfuffle at a high level, all you need to do is read the previous comment carefully.

(Notice that secure boot is an attempt to solve a real problem, not some dastardly plot by mustache-twirling villains, and has real advantages as well as real disadvantages.)

Changing topic: let's all try to avoid making Matthew Garrett's life any harder. Let's all be grateful he's working on this stuff, because we need his work.

LSS: Secure Boot

khim — Sat, 15 Sep 2012 09:59:04 +0000

This attack only makes sense in secure-boot enhanced world. In any other world it's easier to just replace the kernel if you've reached the state where you can do raw disk access.

LSS: Secure Boot

kugel — Sat, 15 Sep 2012 08:15:17 +0000

Thanks. I have never seen this kind of attack