Secure Boot is a broken concept by design.
Secure Boot is completely broken on 200+ models from 5 big device makers
Submitted 3 months ago by Xatolos@reddthat.com to technology@lemmy.world
Comments
Buffalox@lemmy.world 3 months ago
homesweethomeMrL@lemmy.world 3 months ago
To this day, key players in security—among them Microsoft and the US National Security Agency—regard Secure Boot as an important, if not essential, foundation of trust in securing devices in some of the most critical environments, including in industrial control and enterprise networks.
You dare question a monopoly corporation and the spymasters of this country??
(/s)
sugar_in_your_tea@sh.itjust.works 3 months ago
industrial control and enterprise networks
That’s doing a lot of work here.
Yes, it’s important in certain situations, but for consumer devices, it’s just another thing that can go wrong when using alternative operating systems. Regular users don’t have the physical risk these other systems do, and making it more difficult for users to install more secure operating systems goes against the bigger threat.
Linux is compatible with Secure Boot (source: I exclusively run Linux, and use Secure Boot on my systems), but some distros or manufacturers screw it up. For example, Google Pixel devices warn you about alternative ROMs on boot, and this makes GrapheneOS look like sketchy software, when it’s really just AOSP with security patches on top (i.e. more secure than what ships with the device). The boot is still secure, it’s just that the signature doesn’t match what the phone is looking for.
It’s just FUD on consumer devices, but it’s totally valid in other contexts. If I was running a data center or enterprise, you bet I’d make sure everything was protected with secure boot. But if I run into any problems on personal devices, I’m turning it off. Context matters.
capital@lemmy.world 3 months ago
Yes, surely randoms on Lemmy know better than Microsoft and the NSA in regards to security.
cheese_greater@lemmy.world 3 months ago
Can you explain more (don’t doubt you)
ilinamorato@lemmy.world 3 months ago
Ok, so I am not an expert, and I am not the OP. But my understanding is that Secure Boot is checking with a relatively small list of trustworthy signing certificates to make sure that the OS and hardware are what they claim to be on boot. One of those certificates belongs to a Microsoft application called Shim, which can be updated regularly as new stuff comes out. And technically you can whitelist other certificates, too, but I have no idea how you might do that.
The problem is, there’s no real way to get around the reality that you’re trusting Microsoft to not be compromised, to not go evil, to not misuse their ubiquity and position of trust as a way to depress competition, etc. It’s a single point of failure that’s presents a massive and very attractive target to attackers, since it could be used to intentionally do what CrowdStrike did accidentally last week.
But OP might have other reasons in mind, I dunno.
trollbearpig@lemmy.world 3 months ago
Probably to late, but just to complement what others have said. The UEFI is responsible for loading the boot software thst runs when the computer is turned on. In theory, some malware that wants to make itself persistent and avoid detection could replace/change the boot software to inject itself there.
Secure boot is sold as a way to prevent this. The way ot works, at high level, is that the UEFI has a set of trusted keys that it uses to verify the boot software it loads. So, on boot, the UEFI check that the boot software it’s loading is signed by one of these keys. If the siganture check fails, it will refuse to load the software since it was clearly tampered with.
So far so good, so what’s the problem? The problem is, who picks the keys that the UEFI trusts? By default, the trusted keys are going to be the keys of the big tech companies. So you would get the keys from Microsoft, Apple, Google, Steam, Canonical, etc, i.e. of the big companies making OSes. The worry here is that this will lock users into a set of approved OSes and will prevent any new companies from entering the field. Just imagine telling a not very technical user that to install your esoteric distro they need to disable something called secure boot hahaha.
And then you can start imagining what would happen if companies start abusing this, like Microsoft and/or Apple paying to make sure only their OSes load by default. To be clear, I’m not saying this is happening right now. But the point is that this is a technology with a huge potential for abuse. Some people, myself included, believe that this will result in personal computers moving towards a similar model to the one used in mobile devices and video game consoles where your device, by default, is limited to run only approved software which would be terrible for software freedom.
Do note that, at least for now, you can disable the feature or add custom keys. So a technical user can bypass these restrictions. But this isbyet another barrier a user has to bypass to get to use their own computer as they want. And even if we as technical users can bypass this, this will result in us being fucked indirectly. The best example of this are the current Attestation APIs in Android (and iOS, but iOS is such a closed environment that it’s just beating a dead horse hahahah). In theory, you can root and even degoogle (some) android devices. But in practice, this will result in several apps (banks in particular, but more apps too) not working because they detect a modified device/OS. So while my device can technically be opened, in practice I have no choice but to continue using Google’s bullshit.
But at least we are stopping malware from corrupting boot right? Well, yes, assuming correct implementations. But as you can see from the article that’s not s given. But even if it works as advertised, we have to ask ourselves how much does this protect us in practice. For your average Joe, malware that can access user space is already enough to fuck you over. The most common example is ransonware that will just encrypt your personal files wothout needing to mess with the OS or UEFI at all. Similarly a keylogger can do its thing without messing with boot. Etc, etc. For an average user all this secure boot thing is just security theater, it doesn’t stop the real security problems you will encounter in practice. So, IMO it’s just not worth it given the potential for abuse and how useless it is.
It’s worth mentioning that the equation changes for big companies and governments. In their case, other well funded agents are willing to invest a lot of resources to create much sofisticated malware. Like the malware used to attack the nuclear program platns in Iran. For them, all this may be worth it to lock down their software as much as possible. Bit they are playing and entirely different game than the rest of us.
Supermariofan67@programming.dev 3 months ago
It is based on the assumption that every piece of code in the entire stack from the UEFI firmware to the operating system userspace is free of vulnerabilities
dan@upvote.au 3 months ago
lol at the DO NOT TRUST keys.
I’ve learnt over the years that you have to make the example code fail to compile or print out huge user-visible warnings or something like that, otherwise people can and will use it as-is in production, hard-coded keys and all.
Ransack@lemmy.dbzer0.com 3 months ago
That’s on the company for paying pennies for their dev and production roles.
pastermil@sh.itjust.works 3 months ago
What is Secure Boot actually good for? Serious question.
thearch@sh.itjust.works 3 months ago
It’s supposed to prevent unsigned files from being loaded by the UEFI (AFAIK) which could possibly help with rootkits, if it doesn’t somehow sign itself. However, these are pretty rare if you don’t allow sketchy software to access your boot partition, and will often cause issues with non major Linux distros.
bruhduh@lemmy.world 3 months ago
Linux mint is non major? I had dell pc refuse to boot Linux mint because of secure boot
TexMexBazooka@lemm.ee 3 months ago
Speaking from my background, it prevents someone from trying to boot using an external device to access your system, assuming you have a BIOS password in place.
Of course encrypting your drive works just as well, but security in depth demands a “why not both?” Approach
fubarx@lemmy.ml 3 months ago
The repository included the private portion of the platform key in encrypted form. The encrypted file, however, was protected by a four-character password, a decision that made it trivial for Binarly, and anyone else with even a passing curiosity, to crack the passcode and retrieve the corresponding plain text.
It’s like installing a top-of-the-line alarm system for your house with camera, motion detector, alarm, and immobilizing gas, then leaving the unlock password on a PostIt under the welcome mat.
umami_wasbi@lemmy.ml 3 months ago
For anyone interested, that 4 characters is the lowercase in alphabet order.
f4f4f4f4f4f4f4f4@sopuli.xyz 3 months ago
200+ models from 5 big device makers
Nearly 500 device models use them anyway.
Bleeping Computer reports 813 products.
Checked the BIOS update file of a Gigabyte motherboard I have here (Z170X - Gaming 7):
DETECTED PKfail untrusted certificate Issuer: CN=DO NOT TRUST - AMI Test PK
j4k3@lemmy.world 3 months ago
K-rapy garboge!:
There’s little that users of an affected device can do other than install a patch if one becomes available from the manufacturer.
Gentoo gives extensive instructions:
Arch:
NIST (US government guides cover POSIX/Windows with a layperson explanation and guide):
The technical documentation about Secure Boot says that SB is not a mechanisms to steal ownership of your device. It is a spurious claim because the design specification is only a reference and not a requirement. Gentoo has further documentation that can be found describing KeyTool, a package that enables booting directly into UEFI to change the keys manually if your implemented UEFI bootloader lacks the functional implementation required to sign your own keys. I’ve never tried it personally. I merely know of its existence.
ICastFist@programming.dev 3 months ago
Clearly, the solution is to just abandon all
hopehigher level abstraction. Pedal to the metal with Assembly (and maybe LISP and Forth) straight from bootadarza@lemmy.ca 3 months ago
i like how the manufacturers who responded to the author’s queries basically said ‘tough shit, that product is out of support’
Mwa@thelemmy.club 3 months ago
i heard that linux users dont rlly like secure boot
coldy@lemmy.world 3 months ago
I don’t speak for all Linux users, but it’s not like we don’t like the tech or the concept… We don’t like it because a lot of the time it’s just another way for Microsoft to throw around their weight, you need a valid key to sign your kernel images with to be able to boot another OS instead of Windows, and some motherboards don’t support installing your own keys as trusted keys. But usually there are ways around that issue nowadays.
And also it’s not an easy process if you’re not an advanced user of sorts. You have to know what is entailed, what to use, where to store your keys safely, have a script to re-sign the kernel image every kernel update(which happens every week on something like Arch), etc.
Mwa@thelemmy.club 3 months ago
ngl i got fedora secure boot working with microsoft uefi keys
h4lf8yte@lemmy.ml 3 months ago
They don’t like it because it’s mostly implemented in microsofts favor. It’s shipped with microsoft keys by default and needs to be disabled to boot a lot of linux distros. If there was a more unbiased way to load a new os like a default key setup routine at first boot or a preinstalled key for major linux distros they wouldn’t be so hostile towards secure boot. The technology isn’t bad and it’s the only way to not have somebody temper with your system at rest without TPM.
Laser@feddit.org 3 months ago
Which is dumb. Secure Boot does make sense (if handled correctly, unlike here).
Mwa@thelemmy.club 3 months ago
agree
tal@lemmy.today 3 months ago
“It’s a big problem,” said Martin Smolár, a malware analyst specializing in rootkits who reviewed the Binarly research and spoke to me about it. “It’s basically an unlimited Secure Boot bypass for these devices that use this platform key. So until device manufacturers or OEMs provide firmware updates, anyone can basically… execute any malware or untrusted code during system boot. Of course, privileged access is required, but that’s not a problem in many cases.”
I mean, I don’t really have much interest in requiring that my BIOS code be signed, but I have a hard time believing that this Martin Smolár guy is correct. Just entirely disable firmware updates in the BIOS, and re-enable just long for the one boot where you update your BIOS while booting off a trusted USB key. You’d never put your OS in a position of being able to push an update to the BIOS.
SzethFriendOfNimi@lemmy.world 3 months ago
I think Secure boot is intended to check that the boot loader itself is signed.
This is a way to mitigate viruses and malware that infects the boot loader so it can reinstall itself if it’s removed by AV, or something else.
If you can create a boot loader that is signed in such a way that secure boot can’t tell it’s invalid then you can do some nasty stuff.
Closest analogy I can think of is verisigns private key being leaked and there’s no fast and easy way to revoke and replace it without wreaking havoc on currently installed OS’s machines.
Zorsith@lemmy.blahaj.zone 3 months ago
Acer
Dell
Gigabyte
Intel
Supermicro
You’re welcome.
jbk@discuss.tchncs.de 3 months ago
Even Intel lmao
NutWrench@lemmy.world 3 months ago
Damn, Acer. You used to be cool. (a very long time ago)
sugar_in_your_tea@sh.itjust.works 3 months ago
They were always a pretty cheap brand IMO, but pretty reliable. Source: typing this on an Acer monitor that I’ve had for… 10 years?
Vilian@lemmy.ca 3 months ago
o7
harsh3466@lemmy.ml 3 months ago
Doing the lord’s work here!
Antergo@lemmy.ml 3 months ago
You’re missing the additional list mentioned later on, also includes Lenovo and some others