Garrett: Subverting security with kexec

>Well, suppose that Ubuntu removes kexec from its kernels. The old kernel would still be bootable by the Ubuntu GRUB and shim and could be used to subvert Windows security.

> What would happen next? Would Microsoft blacklist the old Ubuntu shim and release a new one that would only load the updated GRUB? How would the updated GRUB figure out which kernels are still secure? Would Ubuntu have to sign them with a new key?

I think this is adequately covered by Matthew later in the thread.

> I think it's very wrong that Microsoft used its market share to get into position of authority. It could get them sued for antitrust violations.
> If Microsoft bosses were smart, they would have handed the secure boot operations over to a non-commercial entity, such as MITRE.

I think you're still missing the point. Microsoft aren't running 'secure boot operations'; the only reason they have to get involved at all is that you can be sure that every system will come with their key pre-installed for obvious economic reasons, and it's fairly safe to assume that nearly no manufacturers will bother including any other keys. That's the inevitable situation regardless of who initiated the standardisation effort, and it's not in Microsoft's control.

Let's say MITRE had a key that they use to sign binaries upon request, and MS provided their binaries to be signed by it. They're still going to be signing those binaries themselves, and vendors would have no reason to bother including the MITRE key when they can cut out the middle man.

Hypothetically, the government could mandate that specific keys owned by a 'neutral' entity must *always* be pre-installed, and then start vigorously enforcing that requirement. That's pretty much the only way you could possibly persuade all the motherboard makers to do the extra work at no benefit for themselves.

You can revoke the Microsoft key in SecureBoot if you don't trust them. Sure, you have to trust that the key is actually removed, but is that really much different than trusting the manufacturer from not putting something in the hardware directly anyways?

That would be interesting if that actually happened because it would be highly visible and undeniable if there were multiple bootloaders, one being clearly malware when reverse engineered, that were both signed by the same key. There is evidence against this theory though in that with Stuxnet they expended a large amount of resources to develop a new and novel hash collision attack to generate a bogus certificate and did not use the actual MS key. This leads me to believe that the NSA doesn't have the ability to access the MS private key, although that could just be what they want you to think 8-).

A salient point is that whatever method is used can only be used once, it will be identified and then be useless.

Driver signing is enforced when Secure Boot is enabled. But yes, a system with unpatched vulnerabilities is obviously still insecure. The point of Secure Boot is to prevent malware from persisting in the system even after the vulnerability is patched.

"malware could still run an unsecured system in a VM"

It's true, it could. But that would be obvious to the user.

Microsoft have made it clear that they'll blacklist anything that's being actively used in attacks.