Linux users are about to face another major Microsoft Secure Boot issue : linux

[–] bhamlin@lemmy.world 47 points 7 months ago

Secure boot can't fail due to expired certificates if it's already disabled...

[+] ook@discuss.tchncs.de 39 points 7 months ago* (last edited 1 week ago) (4 children)

[deleted]

[–] AllrightImmaHeadOut@discuss.tchncs.de 25 points 7 months ago (1 children)

As almost always the answer is "it depends".

From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.

If that's none of your concern, then you probably shouldn't bother with it.

[–] splendoruranium@infosec.pub 9 points 7 months ago (1 children)

As almost always the answer is “it depends”.
From a security perspective you want to make sure that what your system boots is trusted and not tampered with by a third party. If your threat model includes people with physical access or malicious software (root kits) manipulating your operating system, then secure boot can help mitigating if you set it up correctly.
If that’s none of your concern, then you probably shouldn’t bother with it.

It's such a silly system. Could have just had it in a way that automatically trusts only whatever system(s) is/are installed while the BIOS is unlocked so any user benefits from secure boot as soon as they set a BIOS password.

[–] AllrightImmaHeadOut@discuss.tchncs.de 9 points 7 months ago (1 children)

But this breaks automatic updates without entering the BIOS and is just not feasible except for the PC on your desk at home.

[–] splendoruranium@infosec.pub 5 points 7 months ago* (last edited 7 months ago) (2 children)

But this breaks automatic updates without entering the BIOS

Maybe I'm misunderstanding a technical aspect here, but wouldn't only the bootloader need to be signed? To my understanding a tamper-proof system already assumes full disk-encryption anyway, so any kinds of automatic updates would be happening in a black box anyway, wouldn't it?

and is just not feasible except for the PC on your desk at home

That's probably a different and more value-based discussion and I'm quite sure you didn't intend it that way, but it's hard for me to put into words how much this sentence structure offends me 😅
A benefit to the users in front of their personal computers can never be an exception, it is (... ought to be) always the point of everything, the end goal. Having a solution that benefits end users and puts other entities at a disadvantage is always preferable over a solution that puts end users at a disadvantage for the benefit of other entities.

[–] moonpiedumplings@programming.dev 4 points 7 months ago* (last edited 7 months ago) (1 children)

but wouldn’t only the bootloader need to be signed

So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?

To my understanding a tamper-proof system already assumes full disk-encryption anyway

Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one:

I am a laptop owner who wants to prevent tampering with the software on my system by someone with physical access to my device
I am a server operator who wants to enforce usage of only signed drivers and kernels. This locks down modification/insertion of drivers and kernels as a method of obtaining a rootkit on my servers.

The second person does not use full disk encryption, or care about physical security at all, really (because they physically lock up the server racks).

What happens in this setup is that the bootloader checks the kernel's signature, and the kernel checks the driver's signature... and they enable this feature depending on whether or not the secure boot EFI motherboard variable is enabled. So this feature isn't actually tied to the motherboard's ability to verify the bootloader. For example, grub has it's own signature verification that can be enabled seperately.

The first person does not have malware in their system in their threat model. So they can enable full disk encryption, and then they don't care about the kernel and drivers being signed.

EXCEPT THEY ACTUALLY DO BECAUSE NOBODY DOES THE SETUP WHERE THE KERNELS AND DRIVERS ARE ENCRYPTED BY DEFAULT.

You must explicitly ask for this setup from the Linux distro installers (at least, all the one's I've used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.

What I do, is I have /boot/efi be the external EFI partiion. /boot/efi is where the bootloader is installed, and the kernels are stored in /boot, which is located on my encrypted BTRFS partition. The grub bootloader is the only unencrypted part of my system, like the setup you suggested. But I had to ask for this by changing the partitioning scheme on CachyOS, and on other distros I used before this one.

Very interestingly about this setup, is that grub cannot see the config it needs to boot. It guesses at which disk it should decrypt, and if I have a usb drive plugged in, it guesses wrong and my system won't boot.

Continuing, the problem with setups like this is that in order to verify the bootloader, you must have secure boot enabled. Grub will then read this EFI configuration, and attempt to verify the kernels and drivers. As far as I can tell, there is no way to disable this other than changing the source code or binary patching grub.

I have a blog post where I explored this: https://moonpiedumplings.github.io/playground/arch-secureboot/index.html

So this means that even in setups where everything is encrypted except grub, you still have to sign the kernels and drivers in order to have a bootable system (unless you patch grub).

I eventually decided that this wasn't worth it, and gave up on secure boot for now.

[–] splendoruranium@infosec.pub 1 points 7 months ago (1 children)

Thanks, I didn't know most any of that stuff!

So the bootloader also gets updated, and new versions of the bootloader need to get signed. So if the BIOS is responsible for signing the bootloader, then how does the operating system update the bootloader?

Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.

Kinda. The problem here, IMO, is that Secure boot conflates two usecases/threat models into one.

Huh, I think that might indeed be the central problem, good call.

You must explicitly ask for this setup from the Linux distro installers (at least, all the one’s I’ve used). By default, /boot, where the kernel and drivers are stored, is stored unencrypted in another external partition, and not in the LUKS encrypted partition.

Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I'll go back to Veracrypt then.

[–] moonpiedumplings@programming.dev 3 points 7 months ago

Does that happen often? I had, apparently incorrectly, assumed those things were more or less fire and forget.

Bootloaders are also software affected by vulnerabilities (CVE's). But this comment did make me curious. Do the CVE's that affect grub, would a person of threat model/usecase 1 in my comment above care about them?

Many of them do indeed seem to non issues. From the list here.

Grub CVE's requiring the config file to be malicious, like this one are pretty much non issues. The config file is encrypted, in my setup at least (but again, not the default. Also idk if the config file is signed/verified).

I think this one is somewhat concerning. USB devices plugged in could corrupt grub.

Someone could possibly do something similar with hard drives, replacing the one in the system. The big theoretical vulnerability I am worried about is someone crafting a partition in such a way that it does RCE through Grub. Or maybe's it's already happened, my research isn't that deep. But with such a vulnerability, someone could shrink the EFI partition and then put another partition there, that grub reads, and then the code execution exploit happens.

But honestly, if someone could replace/modify hard drives, or add/remove USB devices, what if they just replace your entire system motherboard with a malicious one? This is very difficult to defend against, but you could check for it happening by having your motherboard be password protected, and you always log into your motherboard whenever you boot to make sure the password is the same. (Although perhaps someone could copy over the hashes (at least I am assuming the passwords are hashed) from one motherboard to another).

But if something like that is in your threat model, it's important to note that ethernet, and many other firmware is proprietary (meaning you cannot audit or modify the code), and also has what's called "DMA" — direct memory access. It can read and write to the Linux kernel with permissions higher than root. So if I have access to your device, I could replace your wifi card with a malicious one that modifies stuff after you boot or does any other things.

What you are supposed to do is prevent tampering in the first place, or for a much cheaper cost, have "tamper evident protection", things that inform you if the system was tampered with. Stickers over the screws are an easy and cheap example..

But DefCon has a village dedicated to breaking tamper evident protection. Lol.

I think if your adversary is a nationstate, secure boot usecase 1 is simply broken and doesn't work. It's too easy to replace any of the physical components with malicious one's for them, because there is no verification of those. I think Secure Boot usecase 1 is for protecting against corporate espionage in mid to high tier corpos. Corporations also tend to give people devices, and they can ensure that those devices have tamper evidence/tamper resistance on top of secure boot. Of course I think a nationstate can get through them, but I don't think it's included in the threat model.

Nationstates can easily break the system of secure boot, and probably have methods in addition to or separate from secure boot for protecting themselves.

Wait what, that just seems like home directory encryption with extra steps 🤦 I guess I’ll go back to Veracrypt then.

Performance on LUKS might be better since LUKS is a first class citizen. But maybe performance with veracrypt is better since only the home directory is encrypted. I tried duckduckgo but the top results were AI slop with no benchmarks so I'm not gonna bother doing further research.

[–] AllrightImmaHeadOut@discuss.tchncs.de 2 points 7 months ago

I think I understand why you are offended by this sentence and I'm with you on the benefits of user freedom.

For the first part, yes, technically only the bootloader has to be signed, after that the bootloader is trusted and should do "the right thing".

What I meant was that manually entering the BIOS after an upgrade of the thing you want to boot into (e.g. grub) is not an option for computers that you can't easily access physically, especially in large numbers and located somewhere other than your home. IMHO the system is not "silly", but works well in these scenarios. I agree, that it is not designed to be convenient for end users.

[–] possiblylinux127@lemmy.zip 7 points 7 months ago

It is really important for devices like laptops. A good secure boot implementation will protect against evil maid attacks and prevent people from easily modifying the kernel, initramfs and other critical components while Tue device is powered off.

[–] bonus_crab@lemmy.world 2 points 7 months ago

imo if you dont have disk encryption then thats worse than not having secure boot.

secure boot mainly protects your computer from having certain hardware components and the bios tampered with right?

[–] mvirts@lemmy.world 2 points 7 months ago

For all of my personal machines secure boot is disabled.

The main benefit is enabling signature checks on every piece of code that runs to start your machine. This is a good idea to prevent direct modification of the binaries involved. This will work as far up the chain as software supports, even to userland code although I don't know of any Linux distros do that.

However, if you occasionally rebuild any of that software and can sign it yourself secure boot just moves the attack surface from the binaries into the build process. Any modifications made to the kernel, bootloader, or firmware before signing are included as trusted code and are vulnerable to malicious modification.

Since I don't / can't verify every piece of code on my system, and rebuild Linux occasionally, and people have demonstrated secure boot bypass flaws, I prefer to disable secure boot entirely for convenience. Also, in a roundabout way this increases the security of my system because I won't get locked out for misconfiguring an update.

[–] lyda@programming.dev 26 points 7 months ago (3 children)

All the more reason to buy your computers from companies that support Linux in the first place - like Slimbook and System 76.

[–] possiblylinux127@lemmy.zip 5 points 7 months ago

I know System76 doesn't support Secure boot. I'm not sure about Slimbook.

I wish they would ship a open UEFI implementation with customizable Secure boot keys.

[–] perry@aussie.zone 5 points 7 months ago

And Tuxedo in Germany - just got my InfinityBook pro 14 and it’s been great.

[–] rhythmisaprancer@piefed.social 3 points 7 months ago

Not sure, I have a computer from a Linux builder but it still has UEFI. I am trying to figure out where I stand on this.

[–] Tim_Bisley@piefed.social 22 points 7 months ago

Secure boot security used as ransomware to ensure Windows purchases.

[–] hisao@ani.social 22 points 7 months ago (1 children)

On Bazzite there is a built-in ujust script:

enroll-secure-boot-key # Enroll Nvidia driver & KMOD signing key for secure boot - Enter password "universalblue" if prompted

But I don't really understand how Secure Boot works so far, so I wonder if using it fixes the issue.

[–] CameronDev@programming.dev 27 points 7 months ago (1 children)

That should exactly fix the problem.

The real issue is that by default, if secure boot is enabled, you won't be able to boot up into bazzite or whatever in order to run that command.

So the user experience will be worse now, because instead of just installing and running, Linux users have to disable secure boot, boot and install their distro, run that enroll command, and then reenable secureboot. And lots of people are going to give up at step 1, and leave secureboot off.

[–] 4am@lemmy.zip 9 points 7 months ago* (last edited 7 months ago) (1 children)

Microsoft is counting on that

EDIT: could they just make this part of the install process? Could they make it like a thing that runs on first boot, if you can only do it from within the kernel/boot loader that is to be authorized?

[–] CameronDev@programming.dev 10 points 7 months ago* (last edited 7 months ago) (2 children)

I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn't care what it cost others. But we'll likely never know what their true intent was.

~~I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.~~ Edit: see princessnorah's comments below for more details, but it is a lot more hands on, which prevents malware abusing it.

In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.

Its just not an easy problem to solve.

[–] princessnorah@lemmy.blahaj.zone 6 points 7 months ago (1 children)

I personally dont think MS did it out of maliciousness, more indifference. They wanted the security benefits, and didn't care what it cost others. But we'll likely never know what their true intent was.

They originally tried to design Secure Boot where the OS could never add a key, that would have made sure it never worked for Linux. It wouldn't have prevented Linux from running as long as Secure Boot was disabled, but IIRC a lot of people were worried that manufacturers would end up making it mandatory and it does generally complicate the install process for new users disabling it.

I dont know how the bazzite script does it, but any tool that can be executed from userspace that could add keys could just as easily be abused by malware to add their own signing keys, which completely defeats the purpose.

It just calls the mokutil command which is what's generally used on Linux to enrol keys, it's what the official NVIDIA docs recommend to install the keys for the driver kernel modules. It's just four lines and two of those are echos to make things look prettier for the user.

In an ideal world, Redhat, Canonical, Suse etc could have gotten their verification keys built into every motherboard, but that still cuts out the Arch/Gentoo/flavour-of-the-month crowd. And also increases the risk that a signing key gets leaked and abused by malware.

I mean, everyone is already using a pre-signed "shim" released by Microsoft, that's what this whole situation is about, the certificate for that is about to expire. If RedHat, Canonical, SUSE and Debian all had their own certificates included by manufacturers, they could have released their own "shims" for other downstream distros to use and kept things entirely within the Linux ecosystem. Yes, it would have increased the risk of a signing key getting loose, but I personally trust RedHat still more than Microsoft, even after all the stuff they've done.

Still, it's entirely possible to securely get an OS key into your devices keystore. If you download an ISO onto a trusted device and check it's SHA256 hash against the one provided on the distros website, you can verify its authenticity. Then flash it, disable secure boot on the target system, install it without giving it internet, enrol its keys using similar steps to what the Bazzite script is doing (there are plenty of guides online for various distros) and only then give the new system internet access, the chances of something nefarious worming it's way in are very very slim.

It's also all about your personal threat vector. If you're just an average joe or joette then this is going to be a perfectly acceptable method because no one's going to want to access your system that badly. Corporations are data-hungry, but it's the same rule as bike locks, as long as yours isn't the weakest one on the rack, they're gonna steal a different bike. However, if you're an activist, journalist or (god forbid) a politician, then you should be buying a device that has the new windows key in the BIOS, and not disabling secure boot.

[–] CameronDev@programming.dev 2 points 7 months ago (1 children)

Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.

The other way keys could be securely installed would be for the distros to produce a uefi "addmykey" binary, with their keys baked in to the binary. They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn't boot.

100% agree on the risk profile though, far too many people think they are more important than they really are. Realistically, most of us aren't worth the effort to individually break into our computers.

[–] princessnorah@lemmy.blahaj.zone 4 points 7 months ago (1 children)

Having read up a bit more on mokutil, seems that it doesnt enroll the key by itself, but gets the uefi firmware to prompt the user to add the key at next boot. Which in theory gets around the malware risk, although given how many people auto-click accept, maybe not.

They already thought of that. You don't just hit accept, you then have to type out a password that you set when you run mokutil. So if malware runs it instead, the user just won't know the password at all.

They then get that signed by the MS key, which would allow that image to boot and setup the key without ever disabling secureboot. You wouldnt need to have a trusted PC either, as if the binary was tampered, it wouldn't boot.

Yes, that's exactly how it has worked up until now, more or less. The issue is that the original Microsoft SB key is expiring and old hardware, that's no longer getting firmware updates by the manufacturer, then the new key isn't going to be added ever. If those distros had a key included as well, they likely would have made its expiry a lot longer, because they support hardware for a lot longer. Microsoft doesn't care because Win11 can't run on most of these devices anyway.

[–] CameronDev@programming.dev 3 points 7 months ago (1 children)

Oh, well, if it requires a password that is pretty much solved. The original commentor made it seem a lot less hands on.

I was under the impression that the shim let OS's boot all the way up, and that it was just a standard part of the boot process, I was suggesting instead that the signed binary only let's you add a new key, which you can then use to boot without the shim.

Doesnt help when the key expires though.

Thanks for the additional info, greatly appreciated.

[–] princessnorah@lemmy.blahaj.zone 3 points 7 months ago

Ah yeah, I didn't explain the process fully, my apologies.

[–] MultipleAnimals@sopuli.xyz 3 points 7 months ago* (last edited 7 months ago)

Its just not an easy problem to solve.

So how do we fit AI into this scheme 🤔

[–] oyzmo@lemmy.world 19 points 7 months ago

Nah, don't use it. Secure boot is tainted by Microsoft 🤮

[–] fubarx@lemmy.world 18 points 7 months ago

Another thing to watch out for is fake third-party utilities that will claim they will fix this problem. Unless directly provided from an official Distro itself and is verified, be careful what you download and install.

This is a golden opportunity for malicious actors to get bad code into systems.

[–] mvirts@lemmy.world 8 points 7 months ago (1 children)

My bios doesn't need to know what year it is

[–] TeddE@lemmy.world 5 points 7 months ago* (last edited 7 months ago)

For you and me, that's fine, but for little johnny first time, it's adding friction and new points of failure that push the whole idea further away from their comfort zone.

It could be argued that Microsoft knows this and is deliberately weaponizing peoples insecurities to keep them in line.

Also, "Been available since 2023" means Microsoft gave distros 2-3 years to implement the new signing keys. Yet they'll give themselves decades between signing and updating their own root certificates.

Example: on my work machine, "Microsoft RSA Root Certificate Authority 2017" is valid from 2019 to 2042. It's valid for 25 years, but it took Microsoft 2 whole years to deploy the certificate within it's own structure, specifically to get all the relevant sign-offs needed to issue the cert.

[–] Deebster@infosec.pub 7 points 7 months ago

Has anyone here generated their own keys? I'd looked into it before and it didn't seem too complicated (but never tried).

[–] nshibj@lemmy.world 6 points 7 months ago

In case it helps: I just got an update for "Microsoft UEFI CA" on my computer running Fedora KDE 42, from "Firmware Updates (lvfs)". Check your software centre.

[–] rhythmisaprancer@piefed.social 4 points 7 months ago (2 children)

How would we know if this will affect us? I have been running Linux distros for 20 years and didn't know Microsoft was involved at any level in firmware.

[–] DacoTaco@lemmy.world 10 points 7 months ago (2 children)

It might. It depends on a lot of stuff.
Microsoft was heavily involved in the making of uefi and secure boot but had heavy resistance from canonical as the early drafts of secure boot would not allow os' to add signing keys to the tpm so a machine would only be able to boot windows.

Thankfully canonical won that debate :')

[–] rhythmisaprancer@piefed.social 1 points 7 months ago (1 children)

I definitely have UEFI, not sure about secure boot.

[–] DacoTaco@lemmy.world 2 points 7 months ago* (last edited 7 months ago) (1 children)

A quick way to know is if youre running custom build kernel, or use mainline on ubuntu based systems, youre not using secure boot.
Those kernels are generally not signed and the cert is not added to the tpm to allow it. Youd have to have gone out of your way to do it, in which youd know secure boot was enabled :p

[–] rhythmisaprancer@piefed.social 2 points 7 months ago

Thanks! Currently I am using Mint, and it looks like secure boot is disabled.

Thanks for your replies ❤️

[–] SlartyBartFast@sh.itjust.works 1 points 7 months ago (1 children)

Can I trouble you to elaborate?

[–] DacoTaco@lemmy.world 1 points 7 months ago (1 children)

With? How it could effect us?

[–] SlartyBartFast@sh.itjust.works 1 points 7 months ago (1 children)

Sorry, a baby was kicking me in the face while I typed that. Could you elaborate on the shenanigans that Microsoft had been pulling with regards to the initial draft of the aformentioned standard?

[–] DacoTaco@lemmy.world 3 points 7 months ago* (last edited 7 months ago) (1 children)

A yes, the fun times of a baby haha. Enjoy! :p
Anyway, Secure boot itself was designed by the eufi consortium, which is a group of pc tech companies, to help make sure devices only boot what it can trust. Good on paper and in practice but...

back in circa 2011 microsoft had enforced any pc that wanted to be windows 8 certified ( and get the sticker ) to require secure boot to be enabled together with fastboot. All motherboards needed to have a tpm module with only the microsoft certificate in it. This meant that booting from a usb or cd was completely off the table and you could just not install linux, period.
And even if you did, the kernels or bootloaders were not signed so they would be refused by the bios/eufi.

This was a big thing back then, and canonical and redhat tried and found a few ways around it, and so did some individuals.

But afaik the linux foundation ( which microsoft is part of, funnily enough ) made some binaries that were signed and allowed linux to boot under secure boot, including usb/cd.
Iirc, during the linux installation the distro will add its certificate to the tpm so that kernels signed by the distro boot fine.

To this day, without those binaries from the foundation, it would be impossible to boot linux with secure boot and can still cause issues when dual booting and having bitlocker enabled for example. Bitlocker detects a changed boot state (by grub) and says fuck that, give me the recovery key or i aint decrypting this.

Here is a google search if you want dig deeper, it should all be from circa 2011-2012 :
https://www.google.com/?q=windows+8+oem+to+disable+linux

[–] SlartyBartFast@sh.itjust.works 1 points 7 months ago (1 children)

Wow! That doesn't seem like a very nice thing of Microsoft to do! I would give them a hard stare if I could.

[–] DacoTaco@lemmy.world 2 points 7 months ago (1 children)

Yup! And now we are facing the problems many sys admins face every day all over the world: certificate expirations!
Though instead of https(ssl) certificate of a server expiring, its the certificate used to validate what secure boot boots.
Thats what the article is about

[–] SlartyBartFast@sh.itjust.works 1 points 7 months ago

This is like Y2K all over again

[–] AnUnusualRelic@lemmy.world 6 points 7 months ago (1 children)

As a rule of thumb, if you run any PC hardware at all, then Microsoft is involved in it.

[–] rhythmisaprancer@piefed.social 2 points 7 months ago

Maybe, but what about units supplied by a Linux builder? My last computer was a windows machine I installed Linux on, but that was before this I think. It shipped with windows 7.

[–] phoenixz@lemmy.ca 3 points 7 months ago

Nit knowing secure boot all that well, why isn't there an option in BIOS (I know, I know) to upload the new key manually? That really cannot be that hard...

[+] KiWilly@lemmy.myserv.one -1 points 7 months ago* (last edited 7 months ago)

[removed by mod]