this post was submitted on 18 Jan 2025

154 points (99.4% liked)

PC Gaming

9112 readers

1133 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

EXiLExJD@lemmy.ca

UncleBadTouch@lemmy.ca

KairuByte@lemmy.dbzer0.com

154

New UEFI vulnerability bypasses Secure Boot — bootkits stay undetected even after OS re-install (www.tomshardware.com)

submitted 1 week ago by alessandro@lemmy.ca to c/pcgaming@lemmy.ca

41 comments fedilink hide all child comments

all 42 comments

sorted by: hot top controversial new old

[–] TootSweet@lemmy.world 60 points 1 week ago (4 children)

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.

[–] nik282000@lemmy.ca 23 points 1 week ago

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.

[+] JordanZ@lemmy.world 11 points 1 week ago (2 children)

[deleted]

[–] TootSweet@lemmy.world 6 points 1 week ago

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.

[–] AtariDump@lemmy.world 2 points 1 week ago* (last edited 1 week ago)

It’s like people never learned from the Lenovo Superfish inicdent

[–] Ulrich@feddit.org 4 points 1 week ago (2 children)

Does that mean Linux is invulnerable?

[–] drspod@lemmy.ml 16 points 1 week ago

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.

[–] TootSweet@lemmy.world 8 points 1 week ago

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.)

[–] fmstrat@lemmy.nowsci.com 0 points 1 week ago* (last edited 1 week ago) (1 children)

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?

[–] TootSweet@lemmy.world 1 points 1 week ago

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.

[–] BestBouclettes@jlai.lu 39 points 1 week ago* (last edited 1 week ago)

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 !

[–] krnl386@lemmy.ca 22 points 1 week ago (1 children)

When are we going to see bootloader bypasses/vulnerabilities on mobile devices? Being stuck with the vendor’s shitty Android build sucks.

[–] 9tr6gyp3@lemmy.world 3 points 1 week ago* (last edited 1 week ago) (2 children)

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.

[–] lightnsfw@reddthat.com 8 points 1 week ago* (last edited 1 week ago) (2 children)

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.

[–] noxypaws@pawb.social 0 points 1 week ago (1 children)

Unfortunately, features that should be standard, like headphone jacks and expandable storage, are now mutually exclusive with sufficient security.

You can have your SD card and headphone jack, or you can be secure*. You can't have both.

(*security is never a sure, 100% thing, but on a smartphone connected to so many intimate and financial things it's still your first line of defense)

[–] lightnsfw@reddthat.com -1 points 1 week ago

You can have your SD card and headphone jack, or you can be secure*. You can’t have both.

What about either of those compromises security?

[–] 9tr6gyp3@lemmy.world -1 points 1 week ago (2 children)

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.

[–] SirActionSack@aussie.zone 4 points 1 week ago (1 children)

Using any kind of adaptor for features that have been and still easily could be native is shitty.

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago (1 children)

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.

[–] lurklurk@lemmy.world 2 points 1 week ago (1 children)

The removal of headphone jacks or sdcards have nothing to do with ip68 rating. It's to sell adapters and to make you pay a lot for extra storage

[–] 9tr6gyp3@lemmy.world 1 points 1 week ago* (last edited 1 week ago) (3 children)

Oh man, FYI you can't get an IP68 rating with a headphone jack alone unless you manually cover the slot each time.

[–] lurklurk@lemmy.world 2 points 1 week ago* (last edited 1 week ago) (1 children)

Asus zenphone 10, for example. IP68, headphone jack

I'm sure there are and have been others

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago (1 children)

Its IP65 if the headphone jack isnt covered. Per the manufacturer's website for this phone model:

The device has been tested for water resistance using IEC 60529 standard and has achieved an IP65/68 rating. Water and dust resistance can deteriorate over time in normal usage, or if the device is damaged, repaired or taken apart. The device should never be completely submerged underwater, and should not be allowed to come into contact with seawater, brine, chlorinated water or drinks. Failure to observe correct precautions will invalidate the device warranty and the function of water and dust resistance. Water resistance is tested by submerging the device to a depth of 1.5 meters in tap water for 30 minutes. After the test the device is removed and fully dried, then checked for normal operation. Please note that the device has a USB-C charging port, and this USB-C port must be completely dry before any attempt is made at charging. For related warranty information, please refer to the product warranty card.

[–] lurklurk@lemmy.world 1 points 1 week ago (1 children)

I don't see that mentioning anything about covering the headphone jack before the test. As I understand it, being ip65/68 means it's both, where 65 is "low power spray" and 68 is "immersion", not that it's 68 only if some unspecified conditions are applied

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago* (last edited 1 week ago) (1 children)

I am sorry, I am unable to find any kind of video that shows the Asus Zenfone 10 IP68 test.

I do see this post though: https://zentalk.asus.com/t5/zenfone-10/welp-think-my-zenfone-10-just-died/td-p/414686

As well as a notice from Asus: https://www.asus.com/support/faq/1046136/

[–] lurklurk@lemmy.world 0 points 1 week ago (1 children)

Still nothing to support that it's not actually ip68 rated as advertised.

Perhaps you're just wrong it this? It's fine to be wrong sometimes

[–] 9tr6gyp3@lemmy.world 1 points 1 week ago

I might be

[–] RogueBanana@lemmy.zip 2 points 1 week ago (1 children)

Source?

[–] 9tr6gyp3@lemmy.world -1 points 1 week ago (1 children)

For which phone model would you like me to look up the manufacturer's website for you?

[–] RogueBanana@lemmy.zip 0 points 1 week ago (1 children)

Just have to prove your own words. Leaving your comment here in case you forgot 🙂

"Oh man, FYI you can't get an IP68 rating with a headphone jack alone unless you manually cover the slot each time."

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago (1 children)

Waiting for the phone model so I can pull up the specifications that will have this information. I don't keep a list of phones that have a 3.5mm port on me.

[–] RogueBanana@lemmy.zip 0 points 1 week ago (1 children)

So you don't have any source that shows ip68 specifications mentions anything about headphone jacks. Thanks.

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago (1 children)

Its per phone:

For the sony xperia, check out footnote 5:

https://www.sony.com/electronics/support/mobile-phones-tablets-mobile-phones/xperia-5-iii/specifications

[–] RogueBanana@lemmy.zip 1 points 1 week ago

Exactly my point, some phones has the restriction doesn't mean it is impossible

https://www.samsung.com/us/app/smartphones/galaxy-s9/specs/

This doesn't mention closing any port

[–] Nikki@lemmy.blahaj.zone 1 points 1 week ago (1 children)

say that to my xperia with ip68 and a headphone jack, or my s9+ which had ip68 and a headphone jack, or my s7 that had ip68 and a headphone jack, or...

[–] 9tr6gyp3@lemmy.world 0 points 1 week ago (1 children)

Ok, I'll say that to your xperia, s9+, and s7

Per manufacturer's website for xperia:

This device is water resistant and protected against dust. All ports and attached covers should be firmly closed. Do not put the device completely underwater or expose it to seawater, salt water, chlorinated water or liquids such as drinks. Abuse and improper use of device will invalidate the limited warranty. The device has been tested under Ingress Protection rating IP65/68. Sony devices that are tested for their water-resistant abilities are placed gently inside a container filled with tap water and lowered to a depth of 1.5 meters. After 30 minutes in the container, the device is gently taken out and its functions and features are tested. Note this model has a capless USB port to connect and charge. The USB port needs to be completely dry before charging.

Per manufacturer's website for s9+:

Water-resistant and dustproof based on IP67 Rating, which tests submersion up to 1 meter for up to 30 minutes. Not shockproof.

Per manufacturer's website for s7:

Water-resistant and dustproof based on IP67 Rating, which tests submersion up to 1 meter for up to 30 minutes. Not shockproof.

[–] Nikki@lemmy.blahaj.zone 1 points 1 week ago

xperia 5 iii (my device) official website: https://www.sony.com/electronics/support/mobile-phones-tablets-mobile-phones/xperia-5-iii/specifications

s9+ official website: https://www.samsung.com/levant/support/mobile-devices/galaxy-s9-s9-plus-are-galaxy-s9-and-s9-plus-dust-and-water-resistant-ip68-rating/

s7 official website:

https://www.samsung.com/levant/business/smartphones/galaxy-s/galaxy-s7-g930f-sm-g930fzdamid/

all rated for ip68, all with a headphone jack. every company lacks water damage warranty because of the nature of being unable to tell if you were using it within spec or not.

not the hill i would die on, also confused where the hell you even got those quotes?

[–] lightnsfw@reddthat.com 1 points 1 week ago (1 children)

I don't want to have to carry a dongle around to use things that should be built into the phone.

[–] 9tr6gyp3@lemmy.world 1 points 1 week ago (1 children)

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.

[–] lightnsfw@reddthat.com 0 points 1 week ago (1 children)

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.

[–] 9tr6gyp3@lemmy.world 1 points 1 week ago

Word.

[–] krnl386@lemmy.ca 1 points 1 week ago

So… PinePhone it is then. 🤷🏻‍♂️