In a recent revelation, it has come to light that Microsoft's Secure Boot, a security measure designed to protect devices from firmware infections, has been vulnerable for the majority of its existence. This news, uncovered by researchers at ESET, highlights a critical oversight in the system's implementation.
The issue stems from 'shims', which are essentially extensions to Secure Boot, allowing it to work with Linux devices and utility software. These shims, once signed by Microsoft, can be used to bypass the security feature, leaving both Windows and Linux users exposed to potential threats.
What's particularly concerning is that this vulnerability has existed for over a decade, with Microsoft failing to revoke the defective shims. This oversight has left devices open to attacks, with attackers potentially able to install malicious firmware that persists even after reinstalling the operating system or replacing the hard drive.
The Threat Landscape
The threat of bootkits, or malicious firmware, has been a growing concern, with notable examples like LoJax, MosaicRegressor, CosmicStrand, and BlackLotus making headlines in recent years. These bootkits often require physical access to the device, which is one of the threat models Secure Boot was designed to mitigate.
The list of vulnerable shims compiled by CERT includes those used by prominent Linux distributors and third-party software. Many of these shims were built before certain security measures were implemented, leaving them susceptible to exploits and vulnerabilities.
Complexity and Execution
The complexity of Secure Boot's design, with its multiple databases and revocation methods, may have contributed to the oversight. Microsoft's UEFI bootloader relies on a sole anchor of trust, with all other code executed during bootup requiring explicit signing. Shims, on the other hand, act as a secondary trust anchor, signed by Microsoft, and then authorize further software loads.
The process involves two databases, db and dbx, which list allowed and untrusted certificates, respectively. However, with limited space in the dbx, Microsoft has had to resort to other methods like SBAT and SVN. This complexity, combined with the large number of Linux components, may have led to the lapse in revoking the defective shims.
A Broken Ecosystem
The revelation that attackers have had the means to bypass Secure Boot for over a decade is a damning indictment of the system. HD Moore, a firmware security expert and CEO of runZero, has long been critical of Secure Boot, citing its complexity, lack of scalability, and the ability for components to boot even after certificate expiration.
"The whole ecosystem is somewhat broken and needs a reboot," Moore said. This sentiment is shared by many in the security community, who see this as a wake-up call for a critical reevaluation of the Secure Boot model.
Moving Forward
While Windows users who have installed the June update are now protected, Linux users should check the Linux Vendor Firmware Service or consult their distributor. The revocation statuses can be checked using the uefi-dbx-audit script.
This incident serves as a reminder that even the most sophisticated security measures can have critical flaws. It highlights the importance of continuous monitoring, regular updates, and a proactive approach to security. As we move forward, it's essential to learn from these mistakes and work towards a more robust and reliable security ecosystem.
