Recently we share here on the blog the news about the Problem caused by a Microsoft update in dual boot with Linux distributions that use GRUB. Regarding the incident, we mentioned in the article that the update was "intended" to address a two-year-old GRUB vulnerability, "CVE-2022-2601" that allows attackers to bypass secure boot protections, but far from being a benefit, it ended up harming many users.
Days after the event, Matthew Garrett, a renowned Linux kernel developer, I publish a note in which he explained the operation of the SBAT mechanism. In it, mentions that SBAT was designed to block vulnerabilities in the bootloader without the need to revoke digital signatures, and has been the central element in the recent incident caused by a Windows update that affected some Linux distributions on systems with UEFI Secure Boot, preventing them from booting.
According to Garrett, both Microsoft and some Linux developers share the responsibility of the problem: Microsoft for not having adequately tested the update in all scenarios andlLinux developers for not updating GRUB and SBAT build number when vulnerabilities were discovered in GRUB.
Garrett also mentions that when the UEFI Secure Boot specification was created, everyone involved, to some extent, underestimated its complexity, since
The basic Secure Boot security model states that all code executed in a privileged environment at the kernel level must be verified before execution: the firmware verifies the bootloader, the bootloader verifies the kernel, and the kernel verifies any additional code loaded at runtime. This provides a secure environment for enforcing additional security policies.
Furthermore, it specifies that while there is a possibility of "making mistakes" as such, the specification includes a mechanism to revoke untrusted signed components: simply add the hash of the problematic code to a variable, and refuse to load any code with that hash, even if it is signed with a trusted key.
Up to this point everything sounds good, but Garrett mentions that the problem lies in scale and mainly in fragmentation. of the Secure Boot ecosystem, since Each distribution generates its own files binaries for the bootloader, each with its own hash.
This is why it explains that When a vulnerability is found in the source code of a bootloader, A large number of files need to be revoked different binaries. In addition, the memory available to store a variable containing all these hashes is limited, and there is not enough space to add a new set of hashes Every time a vulnerability is discovered in GRUB and therefore a different solution was needed.
That solution was SBAT.
The concept of SBAT is relatively simple: each critical component within the boot chain declares a security generation number that is included in the signed binary. When a vulnerability is identified and fixed, this generation number is incremented. From there, an update can be issued that sets the minimum acceptable generation. Boot components will review this number to determine if they can run the next item in the boot chain, comparing the name and generation number to the values stored in the firmware variable.
Instead of having to revoke numerous individual hashes, a single update can state: "Any version of GRUB with a security generation lower than this number is considered untrusted."
Linux, the real culprit
Garrett mentions that the error which prevents some systems from booting after the update, It does not come from Microsoft code, but from the shim component from the Linux bootloader.
Although Microsoft released the SBAT update, it is the Linux bootloader that refuses to run old versions of GRUB, making everything work as expected from a technical point of view.
It is because of that the real problem lies in the fact that several Linux distributions have not released updated versions of GRUB that incorporate security fixes and new SBAT generations. This causes these versions of GRUB to be considered insecure, since shim blocks their execution.
It is important to note that GRUB is signed by the Linux distributions themselves, not Microsoft, which eliminates any external delays in updating.
Given Garrett's explanation, mentions that Microsoft released its update to be applied only to Windows (as it should be)) and the problem was on the part of the distributions that were still managing vulnerable versions and generating the problem with dual boot
Finally he mentions that in this incident, Unfortunately, the main victims of this situation are the end users.who suddenly find that they cannot boot the operating system they want.
This is something that should never happen. While I understand the need for UEFI Secure Boot to be enabled by default, and I support Microsoft's decision in general, it's clear that the attempt to prevent the update on dual-boot systems did not work as expected.
If you are interested in knowing more about it, I invite you to consult the original note by Matthew Garrett In the following link.