Eleven old UEFI shim images stayed trusted until Microsoft's June patch release, after ESET researchers found they could help bypass Secure Boot on Windows and Linux devices, Ars Technica reported.

Ars Technica reported that the affected images included at least one from 2013 and had remained signed even after known defects were identified.

Secure Boot is meant to stop malicious firmware from loading before an operating system starts.

Ars Technica reported 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.

Ars Technica reported that Secure Boot was introduced in 2012 to reduce the risk from bootkits, malicious firmware loaded before an operating system starts.

The outlet cited earlier bootkit examples from 2018, 2020, 2022 and 2023, and said 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 needed a copy of an unrevoked shim and a basic understanding of how UEFI shims work, according to the research post cited by Ars Technica.

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 reported.

The outlet said the lapse had lasted for more than a decade in some cases.

The revocation process is complicated because Secure Boot uses multiple trust databases and version controls.

Ars Technica described 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.

The report said 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

Ars Technica reported that the vulnerable shims could be used against Windows and Linux machines, 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, according to the same report.

Linux users were told to check the Linux Vendor Firmware Service or consult their distributor.

The report also cited 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.

Microsoft did not disclose how or why the 11 defective shims stayed trusted before the June revocation.