Boothole is a pervasive vulnerability that affects the GRUB2 boot loader that is used by most versions of Linux.  By exploiting this vulnerability, attackers can run arbitrary code on almost any PC or Server and install RootKits or similar Malware that will persist reboots and be very difficult to detect.

BootHole was first reported by security researchers at Eclypsium.

How Secure Boot works

UEFI Secure Boot is the standard for PC and Servers as the means to secure the operating system boot environment.  Each piece of code that is executed during the boot process has its cryptographic signature checked against an ‘allowed’ and a ‘disallowed’ database. Since there is a huge and increasing number of components and drivers used during the boot process across the plethora of systems the databases do not contain a list of components but rather a list of keys.  If a software component has been signed by a key found in the allow database then the component will be executed; and if the signing key is found in the disallow database the component will not be loaded.

Instead of every OEM having to manage their own keys and certificates for every possible firmware, driver or OS provider, the industry has settled on using the Third Party UEFI Certificate Authority provided by Microsoft.  In short, vendors submit their code to Microsoft who validate and sign it using their universally trusted key. This includes Linux distros as well, not just Windows code.

Due to incompatibilities between licenses, open source projects (ie Linux distros among others) build a small application known as a ‘shim’ and the Secure Boot system loads the shim and the shim loads the Linux bootloader.  The shim is verified against the Microsoft certificate and then the shim loads the GRUB2 and validates its certificate itself.

The Boothole Vulnerability

The GRUB2 boot loader uses a configuration file which identifies the components it will load and execute and the GRUB2 process itself is allowed by Secure Boot.   The Boot Hole vulnerability is a buffer overflow (CVE-2020-10713) in the parser for the GRUB2 configuration file which can be used to trigger arbitrary code execution within the context of the GRUB2 process.  The GRUB2 configuration file is a simple text file which is not signed or otherwise protected except by file system controls – meaning it can be compromised through an escalation of privilege attack.

The code flaw in GRUB2 is actually an error in the design of the error handler for fatal errors – the buffer overflow being one such fatal error.  Examination of the GRUB2 source revealed that the fatal error handler actually does no more than log a console message and then return the calling module; however the calling modules are clearly coded with the assumption that a call to the fatal error handler will never return.  So when any fatal error is raised, it is logged and then execution continues with the next statement.

How to mitigate Boot Hole

At the time of writing, in August 2020, there are numerous reports that the fixes released by several Linux distros to mitigate the Boothole vulnerability are causing systems to fail to reboot.

To resolve the vulnerability fully, GRUB2 needs to be updated to address the vulnerability and then each Linux distro will need to update their installers, bootloaders and shims after getting the shim signed by the Microsoft Third Party UEFI CA.

Once all the updated components have been installed in the field, the UEFI disallow database will need to updated to prevent the vulnerable versions of the code being used in the future.

In the meantime, System Administrators can consider taking the following steps:

• Monitor the EFI system partition to detect unexpected changes, especially to the GRUB2 configuration file grub.cfg.
• Continue to install OS updates to protect against the escalation of privilege attacks needed to alter the EFI partition
• Thoroughly test the revocation list updates and new GRUB2 version on each different device model before widespread deployment
• Update rescue media and Disaster Recovery backups as any bootable components will not work after the disallow database us updated in the EFI firmware.