HELLO, MICROSOFT? YOU THERE? — Something has gone seriously wrong, dual-boot systems warn after Microsoft update Microsoft said its update wouldn’t install on Linux devices. It did anyway.
Dan Goodin – Aug 21, 2024 12:17 am UTC EnlargeGetty Images reader comments 111
Last Tuesday, loads of Linux usersmany running packages released as early as this yearstarted 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 dont 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
Tuesdays update left dual-boot devicesmeaning those configured to run both Windows and Linuxno 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 wasnt detected during testing, or provide technical guidance to those affected. Company representatives didnt respond to an email seeking answers.
Microsofts bulletin for CVE-20220-2601 explained that the update would install an SBATa Linux mechanism for revoking various components in the boot pathbut 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 wouldnt 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. Whats 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.
Further ReadingJust about every Windows and Linux device vulnerable to new LogoFAIL firmware attackThe 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.
Further ReadingSecure Boot is completely broken on 200+ models from 5 big device makersThe 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. reader comments 111 Dan Goodin Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at @dangoodin on Mastodon. Advertisement Promoted Comments SittingDuc It’s unclear to me why Microsoft tried to patch it at all, ever – GRUB is not part of Windows and nothing to do with Microsoft. Why is Windows trying to patch the bootloader of an operating system it knows nothing about?
It’s not surprising this blew up in everyone’s face.The exploit is, a computer with no Linux and with secure boot enabled, can have exploitable grub installed by an attacker .. somehow? .. and then that exploitable grub used to break secure boot and do naughty virus things to the Windows install. Computer with no Linux gets hacked by attacker who brings grub.
Microsoft’s patch is to reject grub during the secure boot of a system that does not have Linux and thus finding grub would be unexpected. So the goal is noble – prevent a boot chain that should not be present from breaking the Microsoft OS.
Unfortunately, the implementation leaves something to be desired; breaking a boot chain that should be present and I fully expect in a few weeks to hear the proposed fix doesn’t stop the exploit it was raised against August 21, 2024 at 12:54 am imeWinder Microsoft said it wouldn’t install on dual-boot systems. Once it’s installed, they’re no longer dual boot systems, right? So they were telling the truth! August 21, 2024 at 12:58 am Channel Ars Technica ← Previous story Related Stories Today on Ars
