Microsoft's Secure Boot, a security feature designed to protect Windows and Linux devices from firmware infections, has been compromised for over a decade, and no one seemed to notice until recently. This revelation has sparked concerns about the effectiveness of the industry-wide standard, which was invented by Microsoft to safeguard devices from bootkits, a type of malicious firmware. The issue lies in the presence of 'shims' - secondary trust anchors signed by Microsoft - that were not revoked when vulnerabilities were discovered. These shims, which were intended to extend Secure Boot to Linux devices and utility software, can be used by attackers to bypass the protection mechanism, which is embedded in the UEFI (Unified Extensible Firmware Interface) of the device's motherboard. The threat is particularly concerning because the shim can be installed on devices running both Windows and Linux operating systems, allowing attackers to subvert the mandated chain of digitally signed firmware and install malicious firmware that persists after OS reinstallation or hard drive replacement. What makes this situation even more alarming is that the vulnerabilities in the shims have been known for over a decade, and Microsoft failed to revoke them until recently, after researchers at ESET identified 11 defective firmware images, including one from 2013. The complexity of Secure Boot, which relies on multiple databases and revocation methods, has contributed to the lapse in security. The process involves the Windows Boot Manager and UEFI shims loading two databases, and for a component to be loaded, it must be authorized through the db and not revoked in the dbx. However, given the high number of Linux components executed during bootup, listing each of them in these databases is not feasible, leading Microsoft to resort to other revocation methods. The shims identified by ESET authorize secondary components that are known to be vulnerable to various exploits, and the skill required to exploit these vulnerabilities is relatively low. This raises serious concerns about the effectiveness of Secure Boot as a security mechanism, and it highlights the need for a more robust and scalable approach to firmware security. In my opinion, the fact that Microsoft has been the de facto root of trust for the entire UEFI platform, and the inability of Secure Boot to scale sufficiently, have contributed to this debacle. The ecosystem is broken and needs a reboot, as HD Moore, a firmware security expert, has suggested. The implications of this vulnerability are far-reaching, and it underscores the importance of staying vigilant and proactive in the face of emerging security threats. As a user, it is crucial to stay informed about the latest security updates and patches, and to take steps to protect our devices from potential attacks. In conclusion, the revelation of the Secure Boot vulnerability is a wake-up call for the industry, and it serves as a reminder of the need for continuous innovation and improvement in the field of firmware security.
