An industry-wide standard Microsoft invented to protect Windows, and later Linux, devices from firmware infections has been trivial to bypass for 13 of its 14 years of existence. The discovery was made by researchers at security firm ESET after identifying 11 firmware images, at least one from 2013, that were known to be defective but remained signed by the software company anyway.
The images are known as shims, which were invented to extend Secure Boot to Linux devices and utility software. Using a technique simple enough to be performed by novice hackers, these old, forgotten shims can be used to completely circumvent the protection, which is embedded into the UEFI (Unified Extensible Firmware Interface) of the device’s motherboard. The gaffe is the result of the failure by Microsoft, which oversees the signing of shims, to revoke the publicly available images once vulnerabilities were found in them.
Threat extends to Windows and Linux users
The threat extends to Windows and Linux users alike, since the shim can be installed on devices running both operating systems. From there, an attacker can subvert the mandated chain of digitally signed firmware to install malicious firmware that loads early in the boot process and persists after either the OS is reinstalled or a hard drive is replaced.
“What makes these old shims dangerous is not a novel vulnerability,” ESET researcher Martin Smolár wrote Tuesday. “It’s that no new vulnerability is needed to bypass UEFI Secure Boot. An attacker needs no complicated exploitation primitives—only a copy of an old, still-trusted, but unrevoked shim binary and a basic understanding of how UEFI shims work. That is enough to bypass such an essential security feature as UEFI Secure Boot.”
Secure boot was introduced in 2012 to blunt the threat of bootkits, the term for such malicious firmware. Without Secure Boot, attackers with brief physical access to a device—even when it’s turned off—can install bootkits similar to LoJax used by Russia state hackers in 2018, MosaicRegressor found in 2020, CosmicStrand in 2022, and BlackLotus in 2023. A handful of other in-the-wild bootkits are tracked under names including ESpecter, FinSpy, and MoonBounce.
In the early days of SB in Linux land we had something like this:
MS CA root > Linux Distro Cert > Linux Distro Cert signed shim (usually GRUB) > kernel (unsigned)
This was convenient because at the time most kernel modules (drivers) were not signed even if the kernel itself could be. See the immediate problem? Yup. One of the problems the article is talking about. If you have a previously signed shim, it can pass off the boot process to any arbitrary boot sequence and you'll never know it. A compromised boot shim implies a compromised certificate chain above it. Why? Because you can substitute any other shim signed by those certificates until they've been revoked - but you only know they've been revoked if the revocation cert is in the store as well. It's not enough to just remove the certificate. Anyone else can simply add it back. Linux distros have been doing that for over 10 years now every install or certificate update.
This is why many people in Linux land don't turn on SB. It's causing more trouble than its worth, given how easily it's bypassed on most hardware. And that's why I pointed out about the two conditions for SB to be useful. A) the UEFI options must default to fail to safe - refuse to boot (which most of the time they don't), B) Microsoft nor the OEMs can be part of the chain of trust, it must be entirely local and auditable. Those two conditions are also why it'll never properly function on consumer grade hardware. There's actually a zeroth condition as well, but that's probably never going to be the case: supervisor mode firmware must be auditable by 3rd parties (Intel's ME & AMD PSP, Arm TrustZone, etc).