Getty Images
On Tuesday, a ton of Linux users, many of them running packages that came out this year, began reporting that their machines wouldn’t boot. Instead, they received a cryptic error message that read, “Something seriously went wrong.”
The culprit: An update Microsoft released as part of its monthly patch release. It was intended to patch a 2-year-old vulnerability in GRUB, an open-source bootloader used to boot many Linux devices. The vulnerability, which had a severity rating of 8.6 out of 10, could allow an attacker to bypass Secure Boot, the industry standard for ensuring that devices running Windows and other operating systems don’t load malicious firmware or software during the boot process. CVE-2022-2601 was discovered in 2022, but for reasons that remain unclear, Microsoft didn’t patch it until this past Tuesday.
Multiple distributions, both new and old, are affected
Tuesday’s update made it impossible for dual-boot devices (that is, devices configured to run both Windows and Linux) to boot into the latter when Secure Boot was enforced. When users tried to load Linux, they were presented with the message, “Failed to verify shim SBAT credentials: Security policy violation. Something went seriously wrong: SBAT self-check failed: Security policy violation.” Almost immediately, support and discussion forums flooded with reports of the failure.
“Please note that Windows says this update does not apply to systems that dual-boot Windows and Linux,” wrote one frustrated person. “This is clearly not true and likely depends on your system configuration and the distribution you are running. It appears that some Linux efi shim bootloaders are not compatible with microcrap efi bootloaders (which is why switching from MS efi to 'other OS' in efi setup works). It appears that Mint has a shim version that does not recognize MS SBAT.”
The reports indicate that multiple distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, Puppy Linux, are all affected. Microsoft has not publicly acknowledged the flaw, explained how it was not detected during testing, or offered technical guidance to those affected. Company representatives did not respond to an email requesting answers.
Microsoft's bulletin for CVE-20220-2601 explained that the update would install an SBAT, a Linux mechanism for revoking various components in the boot path, but only on devices configured to run Windows only. That way, Secure Boot on Windows devices would no longer be vulnerable to attacks that loaded a GRUB package that exploited the vulnerability. Microsoft assured users that their dual-boot systems would not be affected, though it warned that devices running older versions of Linux could experience issues.
“The SBAT value is not applied to dual-boot systems that boot both Windows and Linux and should not affect those systems,” the bulletin said. “Older Linux distribution ISOs may not boot. If this occurs, contact your Linux vendor to get an update.”
In fact the update is has applied to devices that can boot both Windows and Linux. This includes not only dual-boot devices, but also Windows devices that can boot Linux from an ISO image, a USB drive, or optical media. Additionally, many of the affected systems are running recently released versions of Linux, including Ubuntu 24.04 and Debian 12.6.0.
What now?
With Microsoft maintaining radio silence, those affected by the outage have been forced to find their own workarounds. One option is to access their EFI panel and disable secure boot. Depending on the user’s security needs, that option may not be acceptable. A better short-term option is to remove the SBAT that Microsoft released last Tuesday. This means that users will still receive some of the benefits of Secure Boot, even if they remain vulnerable to attacks that exploit CVE-2022-2601. The steps for this workaround are outlined here (thanks to manutheeng for the reference).
The specific steps are:
1. Disable Secure Boot
2. Log in to your Ubuntu user and open a terminal
3. Remove the SBAT policy with:Code: Select all
sudo mokutil –set-sbat-policy remove
4. Reboot your PC and log back into Ubuntu to update the SBAT policy
5. Restart your computer and then re-enable secure boot in your BIOS.
The incident is the latest to underscore what a mess Secure Boot has become, or perhaps always was. In the past 18 months, researchers have discovered at least four vulnerabilities that could be exploited to completely defeat the security mechanism. The most recent example resulted from test keys used to authenticate Secure Boot on approximately 500 device models. The keys were prominently marked with the words “DO NOT TRUST.”
“Ultimately, Secure Boot makes booting Windows more secure, but it seems to have a growing pile of flaws that make it less secure than it should be,” said Will Dormann, a senior vulnerability analyst at security firm Analygence. “SecureBoot gets messy because it's not an MS-only game, even though they hold the keys to the kingdom. Any vulnerability in a SecureBoot component could affect a SecureBoot-enabled Windows-only system. That's why MS needs to address/block vulnerabilities.”
