196
New UEFI vulnerability bypasses Secure Boot — bootkits stay undetected even after OS re-install
(www.tomshardware.com)
this post was submitted on 18 Jan 2025
196 points (99.5% liked)
PC Gaming
9241 readers
289 users here now
For PC gaming news and discussion. PCGamingWiki
Rules:
- Be Respectful.
- No Spam or Porn.
- No Advertising.
- No Memes.
- No Tech Support.
- No questions about buying/building computers.
- No game suggestions, friend requests, surveys, or begging.
- No Let's Plays, streams, highlight reels/montages, random videos or shorts.
- No off-topic posts/comments, within reason.
- Use the original source, no clickbait titles, no duplicates. (Submissions should be from the original source if possible, unless from paywalled or non-english sources. If the title is clickbait or lacks context you may lightly edit the title.)
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
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.
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.
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:
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.
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.
It’s like people never learned from the Lenovo Superfish inicdent
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.)
So, if the UEFI firmware trusts a Microsoft tool that Microsoft trusted a third-party to make and that isn't open source, it's not the firmware provider's fault?
Isn't this like saying it's OK for Boeing to be shit because a subcontractor assembled the plane with poorly investigated used parts?
I wasn't saying anything about who bears "fault". My aim with that post (and honestly all the posts I've made in this thread) was about understanding the details of the vulnerability well enough for folks to be able to ascertain a) whether they're affected and b) how to remediate.
About "fault", I'm not sure I really agree that's the best way to talk about these things in general unless they did them purposefully. (WEI, for instance, was malicious bullshit. But I don't have any particular reason to think in this specific situation Microsoft didn't handle responsible disclosure properly or anything.)
Clearly Microsoft made a boo boo in choosing to trust the vulnerable tools in the first place, but vulnerabilities are inevitable.
I'll definitely say I don't consider Microsoft "trustworthy" enough to protect my stuff. If only because Microsoft stuff is bloated and has a huge amount of attack surface. But also because their history make it clear they'll perpetrate really shitty things against their users on purpose. The former could only really be addressed by them slimming down their technology stack. The latter by abolishing the profit motive.
And also, in general UEFI is apparently a cluster fuck of poor, buggy implementations. So there's that.
In all, this is one doesn't strike me as terribly high on the "blameworthy" meter unless you just consider it a symptom of Microsoft being assholes, which is undeniably true.