Microsoft Revokes 11 Secure Boot Shims After ESET Finds Bypass Risk
Ars Technica reported that ESET found 11 old UEFI shim images that Microsoft still trusted even after known defects. Microsoft revoked the shims in its June patch release, while the reason the lapse lasted for years remains outside the public account.
Eleven old UEFI shim images remained trusted until Microsoft's June patch release, after ESET researchers found they could help bypass Secure Boot on Windows and Linux devices, Ars Technica wrote.
The affected images included at least one from 2013 and had remained signed even after known defects were identified, the outlet noted.
Secure Boot is intended to stop malicious firmware from loading before an operating system starts.
Ars Technica explained that the old shims could let an attacker break the signed boot chain and install firmware that loads early in the startup process, including malware that can survive an operating-system reinstall or hard-drive replacement.
Introduced in 2012, Secure Boot was designed to reduce the risk from bootkits, malicious firmware loaded before an operating system starts.
Ars Technica pointed to earlier bootkit examples from 2018, 2020, 2022 and 2023, while adding that physical device access is one of the threat models Secure Boot is meant to address.
ESET Found 11 Trusted UEFI Shim Images
ESET researcher Martin Smolár wrote that the danger came from old, still-trusted shim binaries rather than a new vulnerability.
The technique required a copy of an unrevoked shim and a basic understanding of how UEFI shims work, based on the research post Ars Technica cited.
A CERT list included shims used by Linux distributors such as Red Hat, OpenSuse and Oracle, as well as third-party software.
Some of the binaries were built before protections such as SBAT and MOK deny lists existed, while others had accumulated bugs in their own code or in second-stage binaries they authorised.
The June Patch Revoked The Defective Shims
Microsoft finally revoked the 11 shims in its regular June patch release after ESET brought them to CERT and Microsoft, Ars Technica wrote.
In some cases, the lapse had lasted for more than a decade, the publication added.
The revocation process is complicated because Secure Boot uses multiple trust databases and version controls.
Ars Technica outlined a db database for allowed signing certificates and hashes, a dbx database for revoked items, and version-based systems including Secure Boot Advanced Targeting and Secure Boot Security Version Number.
Records cited by Ars Technica indicate the dbx database has only 32kb of space, making it impractical to list every Linux component executed during boot.
That limit pushed Microsoft towards version-based revocation mechanisms for vulnerable UEFI applications.
Smolár wrote that SBAT and Microsoft's Secure Boot SVN revoke versions rather than individual binaries.
Each UEFI loader component carries signed metadata with a component name and generation number, and the shim checks that metadata against the minimum version policy before loading itself or other binaries.
Windows And Linux Users Get Different Checks
The vulnerable shims could be used against Windows and Linux machines, Ars Technica found, although Windows 11 Secured-core PCs are likely not exposed in their default state.
Windows users who installed Microsoft's June update batch are no longer vulnerable, the same account stated.
Linux users were advised to check the Linux Vendor Firmware Service or consult their distributor.
Ars Technica also referenced the uefi-dbx-audit script as a way to check revocation status.
Firmware security researcher HD Moore told Ars Technica that the finding rebukes the Secure Boot model, citing Microsoft as the de facto root of trust for the UEFI platform and the number of signed components that can still boot other code.
The public account does not explain how or why the 11 defective shims stayed trusted before the June revocation.
