GoKawiilWhy it matters: A long-standing weakness in a key PC security system stems from a simpler issue: outdated components that were never revoked. Researchers at ESET have found that a set of vulnerable UEFI "shim" bootloaders – some going back to 2013 – remained trusted by Microsoft for years after their flaws were known. As a result, attackers could bypass Secure Boot on both Windows and Linux machines with little difficulty.
The issue affects 11 shim binaries that were still signed and accepted by systems enforcing Secure Boot. That signature is what allows code to run during the boot process. If a trusted component is compromised, everything that follows can be affected.
"What makes these old shims dangerous is not a novel vulnerability," ESET researcher Martin Smolár wrote. "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."
In practical terms, an attacker can use one of these shims to load malicious firmware before the operating system even starts. That kind of malware can stick around through OS reinstalls or even hardware changes like replacing a hard drive.
Secure Boot was introduced in 2012 to prevent exactly this type of attack. It works by requiring every piece of code in the boot chain to be signed by a trusted authority. Microsoft serves as a root of trust in the system, signing its own bootloader and the shims used by Linux and other software.
Shims are essentially a workaround that lets non-Microsoft software run in a Secure Boot environment. Once Microsoft signs a shim, it can approve other components using its own embedded certificates.
That setup only works if vulnerable shims are revoked when problems are found. In these cases, that didn't happen.
The affected shims came from a mix of sources, including Linux vendors such as Red Hat, openSUSE, and Oracle, as well as some third-party tools. Some were created before newer protections like SBAT and MOK deny lists existed. Others contain bugs themselves or allow the loading of known vulnerable components.
ESET pointed to one Oracle shim that allows a binary vulnerable to CVE-2015-5381 to run, noting that exploiting it requires relatively little skill.
Part of the problem is how complicated Secure Boot has become. The system relies on multiple layers – trusted signature databases, revocation lists, and newer version-based controls such as SBAT – to determine what can run. Each piece has to be updated and maintained correctly.
... continue reading