Matthew Garrett, a well-known Linux kernel developer who once received an award from the Free Software Foundation for his contributions to open-source software, explained the essence of the SBAT (Secure Boot Advanced Targeting) mechanism, created to block vulnerabilities in the bootloader without revoking digital signatures, as well as its role in the recent incident involving an update for Windows that led to the failure of some Linux distributions to boot when installed alongside Windows on systems with UEFI Secure Boot enabled. In short, both Microsoft, which didn't fully test the update and applied it to systems it shouldn't have, and the developers of some Linux distributions, who didn't update the GRUB bootloader or SBAT generation number when vulnerabilities were found in GRUB, share the blame.
Below is a translation of Garrett's note:
When the specifications for UEFI Secure Boot were being developed, all participants were, let's say, somewhat naive. The main security model of Secure Boot is that all code running in a privileged environment at the kernel level must be verified before execution—the firmware checks the bootloader, the bootloader checks the kernel, the kernel checks any additional code loaded at runtime, and now we have a trusted environment for enforcing any other security policy we want. Obviously, people can make mistakes, but the specifications included a way to revoke signed components that turned out to be untrustworthy: simply add the hash of the untrustworthy code to a variable, and then refuse to load anything with that hash, even if it is signed with a trusted key.
Unfortunately, it turns out that the problem lies in scale. Every Linux distribution operating within the Secure Boot ecosystem generates its own bootloader binaries, each with its own hash. If a vulnerability is discovered in the source code of such a bootloader, it necessitates revoking a large number of different binaries. The memory allocated for storing the variable containing all these hashes is limited. There simply isn’t enough space to keep adding a new set of hashes every time it turns out that GRUB (the bootloader originally written at a time when boot protection was not practiced, and which has several separate parsers for image files and font files) has yet another mechanism for an attacker to execute arbitrary code, which is why a different solution was required.
This solution is SBAT. The overall concept of SBAT is quite simple. Each important component in the boot chain declares a security generation, which is included in the signed binary file. When a vulnerability is discovered and addressed, this generation number increases. An update can then be released that defines the minimal generation—boot components will look at the next element in the chain, compare its name and generation number to those stored in the firmware variable, and decide whether to execute it or not based on that. Instead of revoking a large number of separate hashes, a single update can simply state: 'Any version of GRUB with a security generation below this number is considered untrusted.'
So why has this suddenly become relevant? SBAT was developed jointly by the Linux community and Microsoft, and Microsoft decided to release an update for Windows that instructed systems not to trust versions of GRUB with a security generation below a certain level. This was done because these versions of GRUB had real security vulnerabilities that allowed attackers to break the secure boot chain of Windows, and we have seen real examples of malware attempting to do this (Black Lotus exploited a vulnerability in the Windows bootloader, but the vulnerability in GRUB was just as effective). From a purely security perspective, this is a perfectly legitimate desire.
Now, regarding the message "Something went completely wrong" and the inability to boot as a result of this update. It is triggered by shim, not by any code from Microsoft. Shim takes into account SBAT updates, and to avoid violating the security principles adopted by other bootloaders in the system, even though Microsoft released the SBAT update, it is the Linux bootloader that, as a result, refuses to boot older versions of GRUB. Everything works as it should.
The problem people faced is that several Linux distributions did not release GRUB versions with the newer security generation, and thus these GRUB versions are considered insecure (it's worth noting that GRUB is signed by the distributions themselves, not Microsoft, so there is no external lag here). In Microsoft's design, the Windows Update was supposed to apply the SBAT update only to systems running solely Windows, while any dual-boot installations would remain vulnerable to attacks until the installed distribution updated GRUB and upgraded the SBAT generation. Unfortunately, as is now clear, this did not work as intended, and at least some dual-boot systems applied the update, while the shim of that distribution refused to load that distribution's GRUB.
What's the bottom line? Microsoft (for understandable reasons) did not want Windows to be attacked via a vulnerable version of GRUB that could be tricked into executing arbitrary code, potentially implanting a bootkit in the Windows kernel during boot. Microsoft addressed this by releasing a Windows update that updated the SBAT variable, indicating that vulnerable GRUB versions should not be loaded on these systems. The first-stage bootloader provided by the distribution read this variable, checked the SBAT section from the installed copy of GRUB, recognized that they conflicted, and refused to load grub with the message "Something went completely wrong." This update was not supposed to be applied to dual-boot systems but was applied nonetheless.
In summary:
1) Microsoft applied the update to systems that it should not have been applied to.
2) Some Linux distributions did not update the GRUB bootloader and the SBAT security generation when vulnerabilities were found in GRUB.
As a result, some people are unable to boot their systems. I believe there are many parties at fault here. Microsoft should have conducted more testing to ensure that dual-boot installations could be accurately recognized. However, distributions providing signed bootloaders must ensure they update them and keep security generations current, because otherwise they provide an attack vector that can be used to compromise other operating systems, which is a kind of violation of the social contract surrounding all of this.
Unfortunately, the victims here are primarily end-users who find that their system suddenly refuses to boot the OS they wish to load. This should never happen. I don't believe that polling end-users about whether they want secure boot updates will yield a good outcome, and while I vaguely lean towards the view that UEFI secure boot is not something that benefits most end-users, it is also something you don't want to discover after incidents like this, so I sympathize with it being enabled by default; hence, I support its default enablement and share Microsoft's choice, except for the failed attempt to avoid updates on dual-boot systems.
In any case, I was heavily involved in implementing this mechanism for Linux back in 2012 and wrote the first prototype of Shim (which is now a significantly better bootloader supported by a wider range of people, and which I haven't touched in several years), so if you want to blame someone, please feel free to blame me. This is not something that should have happened, and if you're not Microsoft or a Linux distribution, it's not your fault. I apologize.
Source: opennet.ru
