If I’m understading what I’ve been able to glean about this just by googling, it looks like the vulnerability is in certain tools that Microsoft has decided to sign with some of its UEFI secure boot keys. It’s not a vulnerability in your UEFI firmware itself, except insofar as your UEFI firmware comes already configured to trust Microsoft’s certificates. So even though the vulnerability isn’t in your UEFI firmware per se, the fix will require revoking trust to keys that are almost definitely pre-installed in your UEFI firmware.
The culprit purportedly comes from a customer PE loader, which allows any UEFI binary to be loaded, even unsigned ones.
They don’t even have to be signed…
Here is an example of something similar that disables Windows Platform Binary Table…(I’m not advocating that anybody actually use this).
WPBT is another terrible ‘feature’ of UEFI/windows that lets motherboard manufacturers install their bloatware even on fresh installs of the OS. First boot of a fresh OS the app will already be installed. Uninstall it and reboot…installed again. You literally need to dig through their bios options to tell it to stop. They usually make that quite the process too. Bios update? You can almost guarantee they turned it back on and probably relocated it in the menus.
They don’t even have to be signed…
Yeah. My understanding is that Microsoft has signed several tools made by other companies that boot as UEFI PE executables and aren’t supposed to allow loading arbitrary (including unsigned and malicious) UEFI PE binaries, but due to security vulnerabilities in the tool, they’ll load any old UEFI PE binary you give them.
The payload/malicious UEFI PE binaries don’t have to be signed. But the third-party tools that contain the vulnerabilities have to be signed by a signer your UEFI firmware trusts. (And the tools are signed by Microsoft, which your UEFI firmware almost definitely trusts, unless you’ve already applied a fix).
(And I don’t know exactly what sort of tools they are. Maybe they’re like UEFI Shell software or something? Not sure. Not sure it matters that much for purposes of understanding the impact or remediation strategy for this vulnerability.)
The fix, I’d imagine is:
- Everyone should untrust the certificates used to sign those vulnerable tools. (And by “untrust”, I really mean they need to apply the revocations.)
- Microsoft needs to issue new certificates to replace the ones with which they signed the vulnerable tools.
- The companies who made those tools need to release new, fixed, not-vulnerable versions of the same tools.
- …and get Microsoft to sign those new versions with the replacement keys.
- And users need to migrate from the vulnerable versions to the new versions of the tools in question.
Now, I’m not 100% sure if there needs to be yet another step in there where individual users explicitly install/trust the replacement certs. Those replacement certs are signed by Microsoft’s root certificate, right? As long as all the certificates in the chain from the root certifcate down to the signature are included with the UEFI PE binary, the firmware should be able to verify the new binary? Or maybe having chains of certs is not how UEFI PE binaries work. Not sure.
Here is an example of something similar that disables Windows Platform Binary Table…(I’m not advocating that anybody actually use this).
Yuck. Thanks for letting me know of that. I’m still firmly in the “learning” phase when it comes to this UEFI stuff. It’s good to be aware of this.
Ever looked at the list of pre-revoked certs that comes on a new mobo? It seems like this is not a new flavour of fuckup.
Does that mean Linux is invulnerable?
No, it means that Linux systems also need to blacklist the keys in their UEFI firmware. I don’t know if distros push updates for those blacklists or if you have to do it manually.
As drspod said, no, Linux is not invulnerable. For Linux users using legacy BIOS boot or using UEFI but not secure boot, this vulnerability doesn’t make anything any more insecure than it was already. But any user, Linux or Windows, who is affected by this vulnerability (which is basically everyone who hasn’t revoked permissions to the Microsoft keys in question), if they’re using secure boot, no they’re not. (That is to say, they can no longer depend on any of the guarantees that secure boot provides until they close the vulnerability.)
It’s pretty funny because at first, people complained about UEFI being too complex and prone to attacks because of it. Turns out they were right !
When are we going to see bootloader bypasses/vulnerabilities on mobile devices? Being stuck with the vendor’s shitty Android build sucks.
Dont buy shitty android phones then. Gotta get the higher end, big name phones that actually take care of the boot loader. Pixel phones come to mind.
I would include any phone that doesn’t have basic features like a headphone jack or a SD card in the “shitty phone” category. Pixel phones come to mind.
Uh, Android supports using sdcards, 3.5mm headphone jacks, and also nvme drives. Literally just get any usb-c adapter for your use case.
Id go for an nvme drives over sdcards though.
Using any kind of adaptor for features that have been and still easily could be native is shitty.
Id rather have a good ip68 rated phone with shitty adapters than a shitty phone with native 3.5mm port and sdcard slot, but to each their own.
I don’t want to have to carry a dongle around to use things that should be built into the phone.
Id rather have a good ip68 rated phone with adapters than a shitty phone with native 3.5mm port and sdcard slot, but to each their own.
I’ve needed my phone to be water proof exactly once in the 20ish years that I’ve had one and that was in 2006. I think I’ll manage without it. I use my headphone jack and SD slot every day.
Word.
