You don't need an exploit or a kernel patch. You just need to replace the firmware's function pointer to GetVariable(), which is a thing you can do because you're running untrusted code in the firmware context. The OS has no way of knowing that you're doing that.
"The GetVariable() call returns a decryption key that the hardware calculated"
No it doesn't. It returns a 1 if the firmware claims to have booted securely, and a 0 if not. You're thinking of Measured Boot, not Secure Boot.
Please describe how Windows can accurately determine whether it was booted in Secure Boot mode or not. For an encore, describe how Trusted Computing can limit the code you can boot. As far as I know, single machine local attestation is an unsolved problem.
How does Windows know whether it was booted in secure mode? It makes the EFI GetVariable() call. Which is a function pointer handed to it by the firmware. Which you can modify if you're running untrusted code. So, no, Windows can't tell.
If you were a serious virus writer you'd already want to use the Microsoft CA to sign your rootkit so you can install it as a signed driver in Windows. Secure Boot moves the vulnerability down the stack, but even now a compromised Microsoft signing key is still massively desirable to virus authors.
Microsoft have told me that they'll revoke certification for any vendor who doesn't provide the appropriate options. If you have examples of machines that have certification and which don't allow any modification of the key database, let me know so we can find out if they were telling the truth.
You've linked to a story about a traditional MBR bootkit that doesn't even run under UEFI. Secure Boot is, as far as anyone knows, not yet cracked.
It's not DRM. You can turn it off in the firmware and there's no way for the OS to know that you did.
BIOS boot sector protection has never prevented writes to the MBR unless you're running DOS - any actual OS uses direct hardware access instead of using the BIOS, and so it can't be blocked. It'd be possible for the BIOS to complain that the MBR's been modified, but it has no way of verifying that the partition boot code or the actual bootloader are still secure. Unsurprisingly, malware authors take advantage of this - https://support.kaspersky.com/viruses/solutions?qid=208280748 has a list of modern bootkits.
Sure. The user shouldn't enrol keys unless they trust whoever provided it and the chain of trust that they assert exists.
Well, that's the point. Nothing you run before reboot will be able to run in the firmware, because it doesn't have the right signature.
No, only the first time you install a given key.
It must be possible to install your own keys, but that may be implemented by allowing you to clear the platform key and switch back to setup mode.
It'll only boot grub if grub is signed with a key that a physically present user has manually enrolled. If you choose to enrol a key that's been used to sign a grub that'll then boot anything (including viruses) then you're vulnerable, but such a virus would only be able to infect systems with that key installed - anyone who hasn't installed that key still gets the protection.
Given that I've been working with the Microsoft people who manage the signing for the best part of a year now, I'm pretty sure they know who I am and what I was getting signed.
Remember to say hello to your bank teller.
