Some days ago, Microsoft released a "security update" which supposedly had the purpose of "Addressing a two-year-old vulnerability in GRUB», but far from helping, the update caused several significant problems on dual-boot systems using Windows and Linux, and as such has resulted in boot disruption on Linux systems when secure boot is enabled.
Vulnerability that is proposed to be addressed with this update is the CVE-2022-2601 In GRUB2, this vulnerability allows attackers to bypass secure boot protections. In response, Microsoft has decided to block Linux bootloaders that have not been patched against this vulnerability, which could prevent Linux systems from booting alongside Windows in dual-boot configurations.
“The vulnerability associated with this CVE is in GRUB2, the Linux boot loader that is designed to support secure boot on Linux systems,” Microsoft notes in an advisory published to address the issue. “This fact is documented in the Security Update Guide, which reports that newer versions of Windows are no longer vulnerable to bypass of this security measure by the Linux GRUB2 boot loader. The SBAT setting does not apply to dual-boot systems running both Windows and Linux and therefore should not affect these systems.”
About the problem
Dual booting, which allows users to install and choose between two operating systems on a single computer, has been negatively affected by this update. In particular, Linux systems using GRUB as bootloaderey have secure boot enabled have experienced crashes after the update.
According to reports, updates to Windows has implemented a new SBAT policy (UEFI Secure Boot Advanced Targeting), designed to block bootloaders by Linux that have not been updated to address the CVE-2022-2601 vulnerability in GRUB2. The issue manifests itself with an error message stating
"Error verifying SBAT data: Security policy violation. Something went very wrong: SBAT self-test failed: Security policy violation."
The SBAT mechanism, developed by Red Hat and Microsoft, It was designed to block vulnerabilities in the GRUB bootloader without the need to revoke the digital signature. SBAT adds metadata to UEFI component executables, which are certified with a digital signature and used to manage the lists of allowed and disallowed components in UEFI Secure Boot. This system allows blocking specific component versions without revoking entire keys, unlike the previous method which required updating UEFI certificate revocation lists (dbx).
The current problem appears to be the result of a lack of testing on Microsoft's part. before the patch was implemented, as well as the lack of updates to some GRUB bootloaders by Linux distribution developers. A translation of Matthew Garrett's detailed analysis of the problem has been published, which highlights that both Microsoft and some Linux developers bear responsibility for this situation.
Regarding the incident, Microsoft only issued a statement:
“This update does not apply when a Linux boot option is detected. However, we are aware that some dual-boot scenarios are causing issues for some users, especially when using outdated Linux bootloaders that contain vulnerable code. We are working with our Linux partners to investigate and resolve this issue.”
For those experiencing the issue, it is recommended that they try disabling Secure Boot in their BIOS/UEFI as a temporary solution, although this may compromise system security.
Another solution is to remove the SBAT data installed in UEFI, install a new Linux distribution with proper support for UEFI Secure Boot (such as Ubuntu), run the command mokutil --set-sbat-policy to remove the SBAT policy and then re-enable Secure Boot.
Updated: If you thought Microsoft released the update with bad intentions, Matthew Garrett comes out to explain Who is responsible for dual boot crash?