Microsoft’s Secure Boot has been broken for a decade and no one noticed until now

Most but not all bootkit malware requires attackers to have physical access to targeted devices. Such access is one of the threat models Secure Boot is explicitly required to protect against. A list of all 11 shims compiled by CERT shows that some were used by Linux distributors such as Redhat, OpenSuse, and Oracle. Others were part of third-party software such as PC-Doctor Finland’s Matriculation Examination Board. Many of them were built before certain protections, including SBAT and MOK deny lists, existed. Others contain accumulated bugs in their code or in second-stage binaries they authorize. Microsoft’s digitally signed UEFI bootloader for Windows is the sole anchor of trust on Windows machines. For a component to load during the boot process, the certificate must explicitly sign all other code executed during bootup. Shims work differently. They’re a secondary trust anchor, and they’re signed by Microsoft using one of its other UEFI certificates. From there, a certificate belonging to the motherboard or software maker that is embedded into the shim authorizes all software that’s subsequently loaded. When vulnerabilities are found in shims, Microsoft revokes them. In the case of the 11 shims, the company failed to do so, in some cases for more than a decade. The company finally revoked them in its regular monthly patch release in June, after ESET brought them to CERT’s and Microsoft’s attention. Microsoft has yet to explain how or why the lapse occurred. One possible cause is the highly complex way that Secure Boot works. Both the Windows Boot Manager and UEFI shims load two databases. The db database lists all allowed signing certificates and Authenticode hashes. The dbx contains certificates and hashes that are no longer trusted. For a component to be loaded, it must be authorized through the db and not revoked in the dbx. Given the high number of Linux components executed during bootup, listing each of them in these databases isn’t possible, since the dbx is allotted only 32kb of space. So Microsoft has resorted to other revocation methods, specifically SBAT (Secure Boot Advanced Targeting) and Secure Boot Security Version Number (SVN). “In short, where dbx revokes binaries, SBAT and Microsoft’s Secure Boot SVN revoke versions,” Smolár explained. “When a vulnerability is found in a UEFI application supporting one of these version-based revocation mechanisms, what really needs to be kept out is every build up to and including the broken one—and that can be captured by a version number much easier than by a long list of hashes.” Further complicating the process, even the expiration of the Microsoft certificate that signed the shims, which took place late last month, isn’t enough to revoke the ones ESET identified. The shims identified by ESET authorize secondary components that are known to be vulnerable to various exploits. The Oracle shim, for instance, signs a binary vulnerable to CVE-2015-5381. Smolár said the skill required to exploit the vulnerability is low. Other vulnerable shims fail to support protections, such as MOK deny-list enforcement and SBAT enforcement, both of which came into effect after the affected shim was released. Still other identified shims contain vulnerabilities in their own code. In the interest of brevity, many additional details included in Tuesday’s report are omitted from this article. As noted, these vulnerable shims can be used against Windows and Linux machines alike, although likely not Windows 11 Secured-core PCs in their default state. Any Windows user who has installed Microsoft’s June update batch is no longer vulnerable. Linux users should check the Linux Vendor Firmware Service or consult their distributor. Revocation statuses are available using the uefi-dbx-audit script. The prospect that attackers have had the means to bypass Secure Boot for more than a decade through what amounts to hack-by-numbers scripts isn’t much of an endorsement of the mechanism proposed by Microsoft in partnership with hardware makers. As mentioned earlier, a key contributor to this debacle is its complexity. “This is a solid rebuke of the entire secure boot model,” HD Moore, a firmware security expert, CEO and founder of runZero, and a long-time critic of Secure Boot, said in an interview. His complaints include Microsoft being the de facto root of trust for the entire UEFI platform, the inability of the protection to scale sufficiently, and the ability for components to boot even after top-level certificates expire. “The end result is a huge number of unknown (to everyone but Microsoft) signed things that bypass Secure Boot—some of which can then be used to boot other things—and both have normal security bugs and other mistakes that mean they can be used to boot nearly anything,” Moore added. “The whole ecosystem is somewhat broken and needs a reboot.”