A critical security feature designed to protect Windows and Linux devices from firmware-level attacks has been vulnerable to simple bypasses for nearly its entire existence due to a longstanding oversight by Microsoft. Security researchers at ESET recently revealed that a set of outdated but still digitally signed "shims" - small software components used to extend the protection mechanism known as Secure Boot - were never revoked despite being known to contain serious vulnerabilities. This failure has effectively rendered Secure Boot circumvention trivial for more than a decade.
### Background on Secure Boot and Shims
Secure Boot is a security standard introduced in 2012 as part of the UEFI (Unified Extensible Firmware Interface) firmware specification. Its primary purpose is to prevent unauthorized and potentially malicious code from running during the early stages of a device's boot process. By enforcing a chain of trust, only firmware and software components signed by trusted digital certificates can load. This mechanism is crucial because malicious firmware, commonly known as bootkits, can persist through operating system reinstalls or hard drive replacements, making them particularly difficult to detect and remove.
Originally designed to protect Windows devices, Microsoft later extended Secure Boot to support Linux by introducing "shims." Shims serve as secondary trust anchors: Microsoft signs the shim binaries themselves, and the shims then verify further components using certificates embedded by motherboard manufacturers or software vendors. This approach was intended to enable Linux distributions and utility software to operate within Secure Boot's framework without compromising security.
### The Discovery of Vulnerable Shims
ESET researchers identified 11 shim binaries, some dating back to 2013, that were known to be vulnerable but remained signed and trusted by Microsoft. Crucially, Microsoft failed to revoke these shims when vulnerabilities were discovered. Revocation is a fundamental security process that removes trust from compromised or outdated components by adding their digital signatures or version numbers to a revocation database.
The failure to revoke these vulnerable shims means that attackers can use them to bypass Secure Boot protections with relative ease. Exploiting this vulnerability requires no advanced hacking skills-only access to a copy of one of these old, still-trusted shim binaries and a basic understanding of how UEFI shims function. This enables attackers to install malicious firmware early in the boot process, giving them persistent control over the device that survives OS reinstallation or physical storage replacement.
This threat affects both Windows and Linux users since the vulnerable shims can be installed on devices running either operating system. The issue is particularly concerning because Secure Boot is explicitly designed to protect against attacks requiring brief physical access to devices, a common attack vector for bootkits.
### The Complexity Behind Secure Boot's Trust Model
Secure Boot's architecture is intricate, involving multiple databases and revocation mechanisms. Two primary databases are involved:
- **db**: Contains allowed signing certificates and hashes of trusted binaries. - **dbx**: Contains revoked certificates and hashes that are no longer trusted.
For a component to load during boot, it must be authorized by the db and not appear in the dbx. However, due to storage limitations (dbx has only 32 kilobytes of space), it is impractical to list every trusted Linux component explicitly. Therefore, Microsoft developed additional revocation mechanisms, such as Secure Boot Advanced Targeting (SBAT) and Secure Boot Security Version Number (SVN), which allow revocation by version numbers rather than individual hashes.
Each UEFI component carries metadata signed alongside its binary, including a generation number that increments with each security update. During boot, the shim checks if the component's generation number meets the minimum required by policy, rejecting outdated or vulnerable versions. The policy and enforcement mechanisms are embedded within the shim itself, allowing updated policies to be applied without exclusive reliance on external variables.
Despite this sophisticated system, Microsoft did not revoke the vulnerable shims identified by ESET for many years, leaving devices exposed. Even the expiration of the Microsoft signing certificate used for these shims last month was insufficient to revoke them.
### Impact and Examples of Vulnerable Shims
The vulnerable shims identified span a range of Linux distributions and third-party software. For example, some shims were used by Red Hat, OpenSUSE, Oracle, and utility software such as PC-Doctor Finland's Matriculation Examination Board. Many of these shims predate protections like SBAT and MOK deny-list enforcement, and some contain known bugs or authorize secondary binaries with known security flaws.
One notable example is an Oracle shim that signs a binary vulnerable to CVE-2015-5381, which requires low skill to exploit. Other vulnerable shims lack support for newer security features or contain flaws in their own code.
### Response and Mitigation
Microsoft finally revoked the problematic shims in its June 2023 monthly security update after ESET reported the issue to CERT and Microsoft. Windows users who have applied these updates are no longer vulnerable. Linux users are advised to check the Linux Vendor Firmware Service or consult their distribution providers for updates. Tools such as the uefi-dbx-audit script can help users verify revocation status.
While this revocation closes the window of vulnerability going forward, the fact that attackers could bypass Secure Boot for more than a decade through relatively simple means calls into question the effectiveness and management of the entire Secure Boot ecosystem.
### Expert Criticism and the Future of Secure Boot
The incident has drawn sharp criticism from firmware security experts. HD Moore, CEO of runZero and a longtime critic of Secure Boot, described the situation as "a solid rebuke of the entire secure boot model." Moore highlighted several systemic issues, including Microsoft's role as the de facto root of trust for the entire UEFI platform and the inability of Secure Boot to scale effectively.
He pointed out that many signed components bypass Secure Boot protections, some of which have their own security bugs or design flaws. The complexity of the ecosystem, combined with Microsoft's centralized control and challenges around certificate expiration and revocation, has resulted in a system that is "somewhat broken" and in need of a fundamental redesign.
### Conclusion
The discovery of these unrevoked, vulnerable shims reveals a critical and long-standing weakness in the Secure Boot security model. What was intended as a robust mechanism to prevent persistent firmware attacks was undermined by Microsoft's failure to revoke compromised components, leaving devices vulnerable to straightforward exploits for over a decade.
While recent patches have addressed these specific vulnerabilities, the incident underscores the difficulties inherent in managing trust in complex, multi-vendor firmware environments. It also raises broader questions about the viability and future of Secure Boot as a security standard, emphasizing the need for greater transparency, improved revocation mechanisms, and potentially, a reevaluation of how firmware security is implemented across the industry.