Microsoft's Secure Boot: Broken for 13 Years by Forgotten Shims

What Happened?

Researchers at security firm ESET discovered 11 defective boot images, known as shims, that remain signed by Microsoft despite having known vulnerabilities since at least 2013. These shims, originally designed to extend Secure Boot to Linux devices and utility software, can be exploited by attackers to completely bypass Secure Boot protection. The technique is simple enough to be executed by novice hackers, according to the ESET report. This finding, reported by Ars Technica, reveals that Secure Boot, a security standard created by Microsoft to protect Windows and later Linux against firmware infections, has been trivial to bypass for 13 of its 14 years of existence.

The problem lies in the fact that Microsoft, which oversees the signing of shims, did not revoke these images once the vulnerabilities were discovered. This has allowed defective shims to be publicly available for over a decade. The flaw is comparable to leaving a master key under the doormat for years. Shims are boot images designed to extend Secure Boot to non-Windows systems, such as Linux distributions and utility tools. Since they are digitally signed by Microsoft, the system considers them trustworthy and allows them to execute during boot. However, the discovered shims contain vulnerabilities that allow an attacker to load unsigned code, breaking the chain of trust.

Why Is This Important?

Secure Boot is a security standard integrated into the UEFI firmware interface of motherboards. Its function is to ensure that only digitally signed firmware and boot software execute during system startup, creating a chain of trust from firmware to operating system. The vulnerability affects both Windows and Linux users, as the shim can be installed on devices with either operating system. Once exploited, an attacker can install malicious firmware that loads early in the boot process and persists even after reinstalling the operating system or replacing the hard drive. This provides firmware-level persistence that is extremely difficult to detect and remove.

The impact is significant. According to ESET data, at least one of the shims dates back to 2013, meaning the exposure window has been over a decade. During that time, any attacker with physical access or administrator privileges could have exploited these images to compromise systems. The simplicity of the technique, described as accessible to novice hackers, exacerbates the risk by lowering the barrier to entry for sophisticated attacks. Organizations that rely on Secure Boot to protect their critical systems, such as enterprise servers, government infrastructure, or Internet of Things (IoT) devices, must review their firmware update policies and consider certificate revocation.

Background and Context

The concept of a shim is not new. It was introduced to allow alternative operating systems, such as Linux, to leverage Secure Boot protections without needing to disable it. However, Microsoft's process for signing shims did not include rigorous long-term security review. Once a shim is signed, it remains valid unless explicitly revoked via an update to the Secure Boot revocation list (DBX). In this case, Microsoft did not issue such revocations, despite the vulnerabilities being known since 2013. This contrasts with previous incidents, such as the BootHole vulnerability in 2020, which affected GRUB2 and required a massive DBX update. On that occasion, Microsoft and other vendors acted quickly to revoke compromised boot loaders. The difference here is the lack of action for years, suggesting a failure in Microsoft's oversight processes.

Historically, Secure Boot has been a cornerstone of boot security but has faced multiple challenges. In 2016, researchers demonstrated that it was possible to bypass Secure Boot on devices with misconfigured firmware. In 2018, vulnerabilities were discovered in the UEFI firmware itself that allowed disabling Secure Boot. However, the current case is particularly severe because the defective shims are signed by Microsoft, granting them an inherent level of trust. As Ars Technica noted, "the error is the result of Microsoft, which oversees the signing of shims, not revoking publicly available images once vulnerabilities were found in them."

What Consequences Will It Have?

The exposure of this vulnerability has serious implications for the security of millions of devices. Attackers could achieve firmware-level persistence, making detection and removal difficult. Organizations relying on Secure Boot to protect critical systems must review their firmware update policies and consider certificate revocation. Microsoft will need to issue security updates to revoke these shims and restore trust in Secure Boot. It is expected that Microsoft will publish a DBX update including the hashes of the defective shims, preventing them from loading on updated systems. However, the distribution process for these updates may be slow, especially in environments with strict update policies.

For home users, the risk is lower, as exploitation requires physical access or administrator privileges. However, in corporate environments, where attackers may gain physical access to devices or escalate privileges through other vulnerabilities, the threat is real. Companies in sectors such as finance, healthcare, or critical infrastructure should consider implementing firmware integrity monitoring and additional secure boot solutions, such as Trusted Platform Module (TPM) and runtime verification measures. Furthermore, this incident underscores the need for hardware and software manufacturers to review their signing and revocation processes to prevent known vulnerabilities from persisting for years.

What Should Readers Know?

Users should ensure they have the latest firmware and operating system updates installed. Companies should implement firmware integrity monitoring and consider additional secure boot solutions. Although the vulnerability is critical, exploitation requires physical access or administrator privileges, reducing the risk for home users but remaining a significant threat for corporate environments. It is recommended that system administrators check whether their devices have affected shims installed and apply DBX updates as soon as they become available. Additionally, they should review secure boot policies and consider temporarily disabling non-essential shims until fixes are issued.

"The technique is simple enough to be executed by novice hackers," the ESET report notes.

In conclusion, this discovery highlights a critical gap in Secure Boot security that has remained open for over a decade. Microsoft's failure to revoke is an error that should serve as a lesson for the entire industry: security does not end with initial signing but requires continuous monitoring and rapid response to known vulnerabilities. Users and organizations must remain vigilant and apply security updates as soon as they become available.