Security researchers at ESET identified a significant vulnerability in Microsoft’s Secure Boot system, revealing that 11 firmware components known as shims remained digitally signed by the company despite containing known defects. The oldest of these vulnerable shims dated back to 2013, meaning the bypass technique has been available for the majority of Secure Boot’s 14-year existence.
Secure Boot is a security feature embedded in device firmware designed to prevent malware from executing during the boot process before the operating system loads. Microsoft created the shims to extend Secure Boot compatibility to Linux devices and utility software. However, the company failed to revoke these shims once vulnerabilities were discovered, leaving them as valid, trusted components that could be exploited by attackers with modest technical skills. The shims affected systems running both Windows and Linux operating systems, and attackers using them could potentially install persistent firmware-level malware that would survive operating system reinstallation or hard drive replacement.
The failure to revoke the vulnerable shims relates to the complexity of Secure Boot’s architecture. Microsoft uses multiple revocation mechanisms, including hash-based denylists and version-based systems such as SBAT and Security Version Numbers. Due to space constraints in the firmware denylists, the company relies on these alternative revocation methods. Some of the identified shims were created before certain protections like SBAT were implemented, while others contained accumulated bugs in their own code or in secondary components they authorized. Microsoft revoked all 11 shims in its June monthly security update after ESET notified the company and relevant authorities.
Industry experts characterized the incident as a significant flaw in Secure Boot’s design and implementation. They noted that the vulnerability highlights issues with centralized trust in the UEFI ecosystem, insufficient revocation mechanisms, and the inherent complexity that may have contributed to administrative oversights. The discovery raised questions about how many other potentially vulnerable firmware components remain signed and unrevoked across the industry.
Article Attribution | Read More at Article Source
Article summary produced by Claude AI