Follow up to: “Something has gone seriously wrong,” dual-boot systems warn after Microsoft update
SBAT was developed collaboratively between the Linux community and Microsoft, and Microsoft chose to push a Windows update that told systems not to trust versions of grub with a security generation below a certain level. This was because those versions of grub had genuine security vulnerabilities that would allow an attacker to compromise the Windows secure boot chain, and we’ve seen real world examples of malware wanting to do that (Black Lotus did so using a vulnerability in the Windows bootloader, but a vulnerability in grub would be just as viable for this). Viewed purely from a security perspective, this was a legitimate thing to want to do.
…
The problem we’ve ended up in is that several Linux distributions had not shipped versions of grub with a newer security generation, and so those versions of grub are assumed to be insecure (it’s worth noting that grub is signed by individual distributions, not Microsoft, so there’s no externally introduced lag here). Microsoft’s stated intention was that Windows Update would only apply the SBAT update to systems that were Windows-only, and any dual-boot setups would instead be left vulnerable to attack until the installed distro updated its grub and shipped an SBAT update itself. Unfortunately, as is now obvious, that didn’t work as intended and at least some dual-boot setups applied the update and that distribution’s Shim refused to boot that distribution’s grub.
…
The outcome is that some people can’t boot their systems. I think there’s plenty of blame here. Microsoft should have done more testing to ensure that dual-boot setups could be identified accurately. But also distributions shipping signed bootloaders should make sure that they’re updating those and updating the security generation to match, because otherwise they’re shipping a vector that can be used to attack other operating systems and that’s kind of a violation of the social contract around all of this.
It’s funny how often Microsoft manages to accidentally do things that just happen to make life more difficult for Linux users. They sure do seem to have bad luck with that.
They also fuck over their own OS. I don’t think they deliberately broke dual boot installs, they simply don’t put enough effort in QA. (See their recent problems with BitLocker after an update. Or that one update that fails because some internal partition is too small. And so on.)
I don’t think Microsoft cares that much anymore. The OS wars are over.
Every Windows now ships with a one-button Linux installer.
Powershell has default aliases so you can use bash commands for basic stuff.
Microsoft is one of the top contributors to the Linux kernel.
They provide documentation on how to install Linux.
They have published a Linux distro.They don’t care cause that’s not where they make their money. Their focus is on keeping their market dominance in Office, Exchange and AD, or M365, Exchange Online and Entra, respectively (all of which can be accessed from Linux). With those products, they can basically demand a tax of ~$20-30/month/employee from every business in the world.
Let’s not forget this is the same company that invented ‘Embrace, Extend, Extenguish’ as a guiding business model behind closed doors. For me, that trust is broken until proven otherwise.
In fairness, anybody who dual-boots invites Microsoft to apply their legendary incompetence to their entire system. And so while I understand that dual-booting is (still, sadly) a totally valid need, people who set up their system for dual-boot kind of make life more difficult for themselves. Microsoft is just being Microsoft here.
use totally ancient linux distribution to run virtual machines!
So they claimed it wasn’t supposed to affect dual boots, yet it was specifically to patch a vulnerability in GRUB, something a Windows-only user has no reason of ever using (that I’m aware of)?
So how could this have affected anyone but people who dual boot? Sketchy.
I believe the idea is that even if the machine is running Windows, an attacker could just boot an affected grub version from a USB to perform the exploit
You, and 62 other people did not read the article.
I don’t dual boot so I had no reason to read the article carefully.
But then again, you did comment on what the article was about. Which would make it relevant to know what the article was about.
And I do, generally. But like I said, I did not read it carefully because I had no reason to.
So if they addressed what I said, I didn’t read that part. 🤷🏻
From one of the comments:
Security settings, for them to have any power at all to block malware, have to be default on and unable to be bypassed by the end user (because the end user will bypass them if they get in the way of whatever task/job they have to do right now).
Emphasis mine.
Are people that cucked now that they’re like “yes, please daddy, lock me out of my own machine”?
The only charitable read of this is the end-user bypassing controls on company-supplied computers.
Of course that doesn’t mean that they won’t also shove secure boot, hw lockouts, DRM, etc on regular consumer laptops as well.
As an admin… end users are generally fucking stupid with regards to technology. I don’t trust the average individual to operate a spoon.
Then you’ll be hopefully setting a UEFI password for them and end of story. Instead of wanting a corporation to lock out everyone of the machines that they own, making sure that no one on earth can boot unsigned Linux either, for example.
deleted by creator
You can’t trust users to make informed decisions about cybersecurity as most users don’t have the necessary background knowledge, so won’t think beyond this popup is annoying me and has a button to make it go away and I am smart and therefore immune to malware. Microsoft don’t want Windows to have the reputation for being infested with malware like it used to have, and users don’t want their bank details stolen. If something’s potentially going to be a bad idea, it’s better to only give the decision to people capable of making it an informed decision. That’s why we don’t let children opt into surgery or decide whether to have ice cream for dinner, and have their parents decide instead.
The comment you’re quoting was replying to someone suggesting a warning popup, and saying it would be a bad idea, rather than suggesting the secure boot UEFI option should be taken away. You need at least a little bit more awareness of the problem to know to toggle that setting.
Is that why they introduced “recall?”
No, that is an entirely unrelated bad decision. It being okay to not have a popup to opt out of secure boot when it does its one job and notices you’re about to run insecure code in kernel mode doesn’t make every other user-hostile thing Microsoft ever does magically okay.
For me there are users, admins and owners, and all levels should have escalating rights to mess with the system. I don’t want a user to have access to security settingsn nor being able to mess with registry or similar stuff. I would prefer a user not being able to do more than read any important part of the HDD too
Yes, they are.
that’s kind of a violation of the social contract around all of this.
What an interesting journey to the conclusion that it’s not the fucking around with non-Microsoft bootloaders that’s wrong, it’s the installing of bootloaders that aren’t approved by Microsoft. That must be somewhere in the Microsoft social EULA you automatically agreed to when you chose to live in a society.
Somebody please tell me which specific CVEs Debian failed to account for in their many grub security updates.
It’s upstream GRUB that’s decided the older GRUB versions are insecure and not to be trusted. Microsoft just propagated that to machines running distros that weren’t shipping patched GRUB builds yet. Up-to-date Debian wouldn’t be affected provided that they downstreamed fixes quickly.
https://fedia.io/m/linux@lemmy.ml/t/1111595/-/comment/6916699 says that Debian’s GRUB wasn’t affected, but another part of the boot sequence was.
Update: According to various indications around the net it turns out that the problem (for Debian users at least) is not grub at all, it’s shim itself. They did update the grub SBAT level in a way that should satisfy Microsoft’s demands when they patched the CVE that everyone seems to be pointing to as the one Microsoft was aiming for.
What they didn’t do in time is update shim (possibly related to CVE-2022-28737, I’m not sure.) There is a new version which has the required change but it has not yet made it to Debian stable. Microsoft added an SBAT for shim as well (which gets checked by shim, so if it’s broken… uh… anyway, it’s probably fine) and it’s the one causing the problems.
(Edited to reflect that I don’t really know if it was the fix for CVE-2022-28737 that was needed, the SBAT variable update related to that, or something else. Whichever it is, the shim update currently in the bookworm proposed updates queue should have it.)
I have secure boot and tpm disabled on my rig. I’ve been called a fool for this. But I don’t understand how it works, and this is an example.
If I was smart enough to code a new OS or a new boot loader (which I’m not) - how does it become different than a virus? Who approves my code is “safe” to run?
Clearly in this case Microsoft said “those versions of grub are not safe.” So what does that mean? I’m not allowed to run them now because Microsoft decided? That’s all it takes? The whole “what’s safe to run” thing baffles me.
Am I supposed to believe that a govt agency like the nsa could NEVER put malicious backdoors into Microsoft’s products, that Microsoft would NEVER allow that to happen, and that code would NEVER be flagged as safe?
I get it…. It helps with obvious viruses and whatnot. But in my experience, all secure boot has ever done for me is cause problems and lock me out of my computer.
Microsoft, by default, decides which code is safe to run, yes.
However, that’s not the only way to use Secure Boot; I enroll my own certificates in addition to Microsoft’s, allowing code that I sign to be booted into. This requires some UEFI setup once.
For most machines, Secure Boot should never lock you out completely; you can always disable it, fix your boot chain and reenable.
I think it’s actually sensible technology, but as every security feature, it usually comes at the cost of some convenience.
What is secure boot even going to protect the average user against though? Is there really any chance of a normal user trying to boot something malicious?
It’s to protect the user against malware that would insert itself in the boot chain and run at higher privilege than the kernel. Just booting a malicious ISO can insert malware in the boot chain without your knowledge. Once you’re in the boot chain, you boot before the kernel, so you can inject whatever drivers you want.
That’s particularly important on corporate computers where they don’t want users to bypass IT policies, but also important for the average Windows user that won’t stop loading malware on their computers. Without secure boot there’s nothing stopping you from forcing yourself local admin privileges or even silently exfiltrate data.
That’s been a thing forever: DOS boot sector malware for example. By only booting signed bootloaders and kernels, you can ensure this doesn’t happen.
I have a friend that abused an insufficiently locked down GRUB to root his workstation at work by using the
init=/bin/shtrick to patch a SUID binary to make his own sudo.But what average user is booting anything other than their hard disk ever in the past like decade? It just seems like an odd attack vector to put so much effort into stopping on consumer devices, it makes sense for businesses though
However, that’s not the only way to use Secure Boot; I enroll my own certificates in addition to Microsoft’s, allowing code that I sign to be booted into. This requires some UEFI setup once.
Do you by chance have a guide or documentation you followed to do this that you could link?
Don’t know how much this would help you; I did this on NixOS, however the steps for creating the key pair and enrolling is the same on all distributions, while your UEFI steps can vary depending on the manufacturer.
https://github.com/nix-community/lanzaboote/blob/master/docs/QUICK_START.md
https://wiki.archlinux.org/title/Unified_Extensible_Firmware_Interface/Secure_Boot for Arch
SBAT summer
lol i dont care, ive stopped dual booting for like a year
