If successfully exploited, BootHole opens up Windows and Linux devices to arbitrary code execution during the boot process, even when Secure Boot is enabled. Meaning an attacker could gain persistence for stealthily installed malware and give them, “near-total control” over the device.
Yeah, yeah, something-something-MALWARE, sure… but also: Can the free software community leverage BootHole to finally achieve freedom to install any code on a UEFI + SecureBoot device? Without having to be allowed by Microsoft by going through their process to sign the distro with their CA?
I’m working on a write-up to explain the vulnerability in a bit more detail in the context of explaining why Purism devices aren’t vulnerable (we’re starting to get asked about it). Your suggestion would only work on devices that haven’t updated their UEFI firmware to versions that have revoked the signatures for vulnerable GRUB2 binaries.
To exploit this, an attacker would need remote administrative access or physical access. In both of those scenarios you may have much bigger problems than this latest exploit.
(For example, the computer that I am on at the moment is vulnerable to this exploit but if someone has physical access to that computer, the most likely scenario is that they are stealing it and I will never see it again, rather than that they are subtly installing an exploit via grub.cfg for further future nefarious activities on their part.)
Yes and no.
I don’t think anyone has ever said that Microsoft is the only permitted signer. Some other large, reputable player in the open source arena could step up and be an alternative.
However there is a philosophical difficulty with the entire approach i.e. you own the computer but any company is the gatekeeper for what software you can boot on your computer.
(I 100% understand that for your typical droid Windows user, implementing a trusted boot path like this is better than not doing so.)
You may be able to bypass this process by getting Microsoft to one-off sign a shim that makes no further validation before loading another executable. So you get UEFI and SecureBoot - but you get zero protection out of it.
What did you actually have in mind regarding “leverage”?
The Ars Technical article referenced in Kyle’s article says that Microsoft is the certificate authority in charge of secure boot signatures.
I think @jon.armani means perhaps this vulnerability could be thought of as an exploit so someone could install any OS in UEFI mode without having to worry about the OS being authorized by Microsoft. Though, honestly, if you’re gonna do that you might as well just disable secure boot. You can still install in UEFI mode without it.
Further to this and to my own post, this would typically imply a blended attack i.e. combining one exploit to get root access from a remote host, in the first place, with this exploit. This would be more sophisticated than the average script kiddie - and might suggest “state actor”, which would imply that you have larger problems than this particular exploit.
One problem here is that, I would think, it will take a few months to get this fix rolled out. So if your computer is vulnerable now, it will remain vulnerable for quite some time. Fixing this is definitely more than “just update GRUB2”, unfortunately.
