Last Tuesday, loads of Linux users—many running packages released as early as this year—started reporting their devices were failing to boot. Instead, they received a cryptic error message that included the phrase: “Something has gone seriously wrong.”
The cause: an update Microsoft issued as part of its monthly patch release. It was intended to close a 2-year-old vulnerability in GRUB, an open source boot loader used to start up many Linux devices. The vulnerability, with a severity rating of 8.6 out of 10, made it possible for hackers to bypass secure boot, the industry standard for ensuring that devices running Windows or other operating systems don’t load malicious firmware or software during the bootup process. CVE-2022-2601 was discovered in 2022, but for unclear reasons, Microsoft patched it only last Tuesday.
Multiple distros, both new and old, affected
Tuesday’s update left dual-boot devices—meaning those configured to run both Windows and Linux—no longer able to boot into the latter when Secure Boot was enforced. When users tried to load Linux, they received the message: “Verifying shim SBAT data failed: Security Policy Violation. Something has gone seriously wrong: SBAT self-check failed: Security Policy Violation.” Almost immediately support and discussion forums lit up with reports of the failure.
“Note that Windows says this update won’t apply to systems that dual-boot Windows and Linux,” one frustrated person wrote. “This obviously isn’t true, and likely depends on your system configuration and the distribution being run. It appears to have made some linux efi shim bootloaders incompatible with microcrap efi bootloaders (that’s why shifting from MS efi to ‘other OS’ in efi setup works). It appears that Mint has a shim version that MS SBAT doesn’t recognize.”
The reports indicate that multiple distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, Puppy Linux, are all affected. Microsoft has yet to acknowledge the error publicly, explain how it wasn’t detected during testing, or provide technical guidance to those affected. Company representatives didn’t respond to an email seeking 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 only Windows. 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 their dual-boot systems wouldn’t be affected, although it did warn that devices running older versions of Linux could experience problems.
“The SBAT value is not applied to dual-boot systems that boot both Windows and Linux and should not affect these systems,” the bulletin read. “You might find that older Linux distribution ISOs will not boot. If this occurs, work with your Linux vendor to get an update.”
In fact, the update has been applied to devices that boot both Windows and Linux. That not only includes dual-boot devices but also Windows devices that can boot Linux from an ISO image, a USB drive, or optical media. What’s more, many of the affected systems run recently released Linux versions, including Ubuntu 24.04 and Debian 12.6.0.
What now?
With Microsoft maintaining radio silence, those affected by the glitch have been forced to find their own remedies. One option is to access their EFI panel and turn off secure boot. Depending on the security needs of the user, that option may not be acceptable. A better short-term option is to delete the SBAT Microsoft pushed out last Tuesday. This means 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 remedy are outlined here (thanks to manutheeng for the reference).
The specific steps are:
1. Disable Secure Boot
2. Log into your Ubuntu user and open a terminal
3. Delete the SBAT policy with:Code: Select all
sudo mokutil –set-sbat-policy delete
4. Reboot your PC and log back into Ubuntu to update the SBAT policy
5. Reboot and then re-enable secure boot in your BIOS.
The incident is the latest to underscore what a mess Secure Boot has become, or possibly always was. Over the past 18 months, researchers have unearthed at least four vulnerabilities that can be exploited to completely neuter the security mechanism.
The prior most recent instance was the result of test keys used to authenticate Secure Boot on roughly 500 device models. The keys were prominently marked with the words “DO NOT TRUST.”
“At the end of the day, while Secure Boot does make booting Windows more secure, it seems to have a growing pile of flaws that make it not quite as secure as it’s intended to be,” said Will Dormann, a senior vulnerability analyst at security firm Analygence.
“SecureBoot gets messy in that it’s not a MS-only game, though they have the keys to the kingdom. Any vulnerability in a SecureBoot component might affect a SecureBoot-enabled Windows-only system. As such, MS has to address/block vulnerable things.”
