Late last month, security researchers discovered a major vulnerability in the software that controls how PCs boot their operating systems. This is one of those issues that sounds scarier than it is. Fixing it will be a major process, especially for Linux system administrators and corporate IT organizations with a mixture of different PC vintages and manufacturers. The problem has been named BootHole, and it could affect up to a billion computers.

The role of Secure Boot

The issue has to do with the Unified Extensible Firmware Interface (UEFI) Secure Boot process that has been used since 2012 to ensure that the boot sector is using trusted code, before a computer loads the actual OS. This post on Debian’s website explains how that process works and the main cause of the vulnerability with a piece of software called the Grand Unified Bootloader (GRUB2) that is widely used to boot Linux systems. While Windows doesn’t use GRUB2, these PCs could also be compromised – including all versions of desktop since 8.1 and server since 2012. This is probably why that 1 billion number is probably as high as it is. Microsoft created the Secure Boot process and supplies the trusted and signed cryptographic keys, as well as the signed boot code firmware, to Linux vendors, so they can take advantage of this security feature.

Without a functional Secure Boot, hackers who have either physical PC access or administrative rights can control how an OS is loaded and compromise the entire machine for their own purposes. This is an important caveat, and perhaps an important reason why BootHole isn’t as bad as it first sounds – there are plenty of ways to compromise a computer already that are much worse. (The first link by Eclypsium, cited above, goes into the code architecture and how its various components interact.)

Fixing the hole

The vulnerability has set off a fury of engineering changes to the Secure Boot process, taking advantage of the moment to essentially rebuild it from scratch and harden it. For example, various Secure Boot elements need to be signed – such as the configuration file that is used to direct its actions. Once a new GRUB2 module is created and tested, then the existing crypto keys need to be revoked and reissued, so that they aren’t used to compromise any systems. Microsoft is responsible for these keys and uses what is called the UEFI Forbidden Signatures Database or DBX to contain this blacklist of revoked keys. The DBX needs to be updated to block the vulnerable GRUB2 versions, and some vendors have begun to issue these updates. But you’ll need a new GRUB2 version to match the latest DBX to be completely protected.

Unfortunately, these changes will take time to roll out – Microsoft isn’t planning on delivering an update to address BootHole until it finishes further testing sometime in 2021. If you were to update and reboot your PC, it may stop working, which has been already reported in the days since the vulnerability was announced. All the various bits and pieces have to be updated, tested and available for download. In the meantime, manual updates are suggested with care. System administrators should test the DBX updates with your particular set of firmware and PC vintage to ensure it all works properly.

Various vendors have issued alerts and advisories, and a good short overview of what is involved in mitigating BootHole can be found in this two-page document from the NSA. Aside from Microsoft and Debian, HP has released this update to the UEFI DBX here, Ubuntu has this bulletin, and Red Hat said that the bug affects at least Red Hat Enterprise Linux 7 and 8. Red Hat users should follow the instructions mentioned in this Ars Technica post. 

In addition to these systems, the researchers have found 80 different Linux versions that are at risk, including embedded IoT devices – these gadgets, such as home controls and routers, could potentially take much longer to find and properly update. 

If you are running Linux, do your homework before rebooting or upgrading so you don’t make things worse. If you are running Windows, you’re better off waiting for Microsoft to issue a fix.  In the meantime, use basic security hygiene to avoid unwanted access to your machine. Always keep your computer password protected and restrict administrator access to avoid the most of this vulnerability’s risk.