Critical flaw in Microsoft’s Secure Boot allowed security bypass for more than ten years
Secure Boot protection, an industry standard developed by Microsoft to protect Windows and Linux devices against firmware infections, has recently failed to be circumvented for 13 of its 14 years of existence. This vulnerability was revealed by experts from ESET, a security company, who detected 11 firmware images, one of which dated 2013, which were known to be flawed, but remained approved by the software giant.
These images, called “shims”, are designed to extend Secure Boot to Linux systems and utility software. Using a method accessible even to inexperienced hackers, these old and neglected shims could completely bypass the security of the UEFI (Unified Extensible Firmware Interface), present on the motherboard. The origin of the failure lies in the omission of Microsoft, responsible for validating the shims, in not canceling the approval of public images when the weaknesses were discovered.
The scope of this threat extends to users using both Windows and Linux.
This risk affects users of both operating systems, as the shim can be deployed on Windows or Linux devices. Once installed, a cybercriminal can bypass the digitally signed firmware sequence, introducing malicious software that is activated during the initial boot phase and remains even after reinstalling the operating system or changing the hard drive.
ESET researcher Martin Smolár explained on Tuesday that “What makes these old shims dangerous is not a new vulnerability. It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker doesn’t need complex exploitation primitives — just a copy of an old, still trusted but unrevoked shim binary and a basic understanding of how UEFI shims work. That’s enough to bypass a security feature as essential as UEFI Secure Boot.”
Created in 2012, Secure Boot was intended to reduce the risk of “bootkits”, which are malicious firmware. Without this functionality, cybercriminals with quick physical access to a device, even if it is turned off, could install bootkits. Examples include LoJax, used by Russian hackers in 2018; MosaicRegressor, detected in 2020; CosmicStrand, in 2022; and BlackLotus, in 2023. Other active bootkits are known as ESspecter, FinSpy and MoonBounce.
More on this story: Critical Windows security update will require multiple restarts
Most, but not all, bootkits require attackers to gain physical access to compromised devices. This type of access represents one of the threat scenarios that Secure Boot is explicitly designed to combat.
A CERT survey revealed that some shims were employed by Linux distributions such as Red Hat, OpenSUSE, and Oracle. Others were integrated with third-party software, such as PC-Doctor Finland’s Matriculation Examination Board. Several were developed before certain safeguards were implemented, such as the SBAT and MOK blocklists. Additionally, some contained accumulated flaws in their code or in the second-stage binaries that authorized them.
For Windows computers, Microsoft’s UEFI bootloader, which has a digital signature, is the only trust factor. For a component to be activated during the boot process, its certificate must explicitly sign all code executed during boot.
The functioning of shims is different. They act as a secondary trust point, being validated by Microsoft through one of their alternative UEFI certificates. From that point on, a certificate from the motherboard or software manufacturer, already inserted into the shim, authorizes all subsequent programs that are loaded.
Typically, when flaws are identified in shims, Microsoft revokes them. However, with the 11 shims in question, the company failed to act, keeping them active for over a decade in some scenarios. Microsoft only canceled them in its June monthly patch update, after ESET alerted CERT and the company itself about the issue.
Why the complexity of Secure Boot makes digital security difficult
Full coverage: Latest News (EN)
Microsoft has not yet provided details on how or why this flaw manifested itself. A main hypothesis points to the intrinsic complexity of how Secure Boot works. The Windows Boot Manager and UEFI modules use two databases: the “db”, which lists all allowed signing certificates and Authenticode hashes; and “dbx”, which stores certificates and hashes that are no longer considered trustworthy. For any component to be loaded, it must be authorized by the “db” database and not be listed as revoked in “dbx”.
See Also
Michigan serial killings result in six deaths, including US suspect
7.7 magnitude earthquake destroys buildings in Indonesia and triggers tsunami warning
Videos of the 7.7 earthquake in Indonesia reveal damage and panic in Asia
Given the vast number of Linux components that are executed during startup, cataloging each of them in these databases is impractical, especially since the dbx file has a limit of just 32 KB. Faced with this limitation, Microsoft implemented other revocation mechanisms, such as SBAT (Secure Boot Advanced Targeting) and Secure Boot Security Version Number (SVN).
“In short, while dbx revokes binaries, SBAT and Microsoft’s Secure Boot SVN revoke versions,” Smolár detailed. He added: “When a vulnerability is found in a UEFI application that supports one of these version-based revocation mechanisms, what really needs to be protected is the entire build prior to and including the vulnerable version — and this can be captured by a version number much more easily than by a long list of hashes.”
Each component within the UEFI loader has metadata that is signed by the same certificate that authenticates the binary itself. This metadata identifies the component and assigns it a generation number, which is updated with each new security fix released.
In the UEFI environment, a specific boot variable stores the minimum tolerable generation number for each component. It is the shim, not the firmware, that establishes the value of this variable.
The shim also integrates the security policy, ensuring that its application does not depend solely on the external variable. This makes it possible to include new policies through a mechanism called SbatLevel.
“At each launch, the shim first checks its own SBAT metadata against the policy — so an outdated shim can be configured to reject itself — and then applies the same test to all binaries it loads, rejecting anything whose generation number is below the minimum required by the policy,” the researcher described.
Learn more: Microsoft warns about Windows 11 security certificates expiring in June
The intricate nature of the process is not limited to these aspects. Consequently, shims contain a vendor-managed certificate and an internal certificate, both authorizing all bootloaders and utilities that are loaded in sequence.
To add another layer of complication to the procedure, not even the expiration of the Microsoft certificate that validated the shims, which occurred at the end of the previous month, was enough to invalidate the certificates detected by ESET.
Identification of vulnerable shims and their specific failures
ESET-localized shims grant permission to minor components that are proven to be susceptible to various exploits. Oracle’s shim, for example, validates a binary vulnerable to CVE-2015-5381. Smolár emphasized that the level of technical knowledge to exploit this flaw is low. Additionally, other compromised shims do not support protections such as the MOK blocklist and SBAT enforcement, both of which were introduced after the affected shim was released. There are also identified shims that contain vulnerabilities in their own code.
Implications of the failure and recommendations for users
As already pointed out, these vulnerable shims can be employed against Windows and Linux devices, although they are less likely to affect PCs running Windows 11 Secured-Core in their native configuration. Windows users who installed Microsoft’s June update package are now protected. For Linux users, the recommendation is to check the Linux Vendor Firmware Service or contact your distributor. The revocation status can be queried using the uefi-dbx-audit script.
The scenario of attackers being able to bypass Secure Boot for more than a decade, using highly automated scripts, is not a positive indication for the mechanism designed by Microsoft in collaboration with hardware manufacturers. The complexity of the system, as mentioned, is a determining factor in this situation.
“This is a strong criticism of the entire secure boot model,” said HD Moore, firmware security expert, CEO and founder of runZero, and a longtime critic of Secure Boot, in an interview. Among his reservations, he cited Microsoft being the main trust authority for the entire UEFI platform, the limitation of protection in being adequately scalable and the permission for components to be initialized even after the expiration of higher-level certificates.
Moore added: “The end result is a huge number of signed items (unknown to everyone except Microsoft) that bypass Secure Boot — some of which can be used to boot other systems — and both of which have common security holes and other errors that allow them to be used to boot virtually anything.” He concluded by stating that “the entire ecosystem is somewhat compromised and needs a reset.”
