Getty Images
Last Tuesday, a number of Linux users, many running packages released this year, began reporting that their devices would not boot up. Instead, they received a cryptic error message that included the following phrase: “A serious problem has occurred.”
The culprit was an update released by Microsoft as part of its monthly patch release. It was intended to close a two-year-old vulnerability in GRUB, the open-source bootloader used to boot many Linux devices. The vulnerability, which has a severity rating of 8.6 out of 10, allowed hackers to circumvent Secure Boot, an industry standard that prevents devices running Windows and other operating systems from loading malicious firmware or software during the boot process. CVE-2022-2601 was discovered in 2022, but for unknown reasons, Microsoft only patched it last Tuesday.
Multiple distributions, both old and new, are affected
Tuesday’s update prevented dual-boot devices (devices that are set up to run both Windows and Linux) from booting into Linux when Secure Boot was enforced. When users tried to load Linux, they received the message “Failed to validate shim SBAT data: Security policy violation. A critical problem occurred: SBAT self-check failed: Security policy violation.” Support and discussion forums were almost immediately flooded with reports of the failure.
“Windows states that this update does not apply to systems that dual boot Windows and Linux,” one disgruntled person wrote. “This is obviously not true and may vary depending on your system configuration and the distribution you’re running. It appears that some Linux efi shim bootloaders are no longer compatible with the microcrap efi bootloader (so switching from MS efi to “other OS” in efi setup works). Mint appears to have a shim version that MS SBAT doesn’t recognize.”
Several distributions, including Debian, Ubuntu, Linux Mint, Zorin OS, and Puppy Linux, are all reportedly affected. Microsoft has yet to officially acknowledge the error, explain why it wasn’t detected during testing, or provide any technical guidance for affected users. Company representatives did not respond to an email seeking response.
Microsoft’s security bulletin on CVE-20220-2601 explains that the update installs SBAT, a Linux mechanism that disables various components in the boot path, but only on devices configured to run Windows only. This makes Secure Boot on Windows devices less vulnerable to attacks that load GRUB packages that exploit the vulnerability. Microsoft assured users that dual-boot systems are not affected, but warned that devices running older versions of Linux may experience issues.
“The SBAT value does not apply to dual-boot systems that boot both Windows and Linux, so these systems should not be affected,” the bulletin states. “ISOs from older Linux distributions may not boot. If this occurs, contact your Linux vendor for an update.”
In fact, this update is being applied to devices that boot both Windows and Linux, including dual-boot devices as well as Windows devices that can boot Linux from an ISO image, USB drive, or optical media. Additionally, many of the affected systems are running recently released versions of Linux, such as Ubuntu 24.04 or Debian 12.6.0.
What next?
Microsoft’s silence has left affected users to take their own steps. One way is to go into the EFI panel and turn off Secure Boot. Depending on your security needs, that option may not be acceptable to you. In the short term, you’re better off removing the SBAT that Microsoft pushed out last Tuesday, meaning users will still get some of the benefits of Secure Boot, even if they remain vulnerable to attacks that exploit CVE-2022-2601. We’ve outlined the steps to do so here (thanks to manutheeng for the references).
The specific steps are as follows:
1. Disable Secure Boot
2. Log in to your Ubuntu user and open a terminal
3. Remove the SBAT policy with the following command:Code: Select All
sudo mokutil –set-sbat-policy remove
4.Reboot your PC and log back into Ubuntu to refresh the SBAT policies.
5. Reboot and re-enable Secure Boot in the BIOS.
This incident is the latest to highlight just how confusing Secure Boot is, or has always been. Over the past 18 months, researchers have found at least four vulnerabilities that could be exploited to completely disable the security mechanism. The most recent example before that was the result of a test key used to authenticate Secure Boot on roughly 500 different device models. The key prominently featured the words “DO NOT TRUST.”
“Ultimately, Secure Boot makes Windows boot more secure, but it seems to be riddled with flaws that don’t make it as secure as intended,” says Will Dorman, senior vulnerability analyst at security firm Analygence. “Secure Boot is tricky in that it’s not just MS’s game, but MS holds the keys to the kingdom. Vulnerabilities in Secure Boot components can affect Windows-only systems that have Secure Boot enabled, so MS needs to address/block anything vulnerable.”
