'BootHole' Vulnerability Exposes Secure Boot Devices to Attack

A newly discovered vulnerability in the GRUB2 bootloader, dubbed BootHole, may threaten Linux and Windows machines using Secure Boot. Attackers who exploit it could interfere with the boot process and control how the operating system (OS) is loaded, bypassing security controls.

The boot process is critical to securing any device. It relies on a variety of firmware to initialize and control different components of a machine, and it coordinates how the OS is loaded.

"During the boot process, anything that loads earlier is generally higher privilege than something that loads later," says Jesse Michael, principal researcher with Eclypsium, where researchers discovered BootHole (CVE-2020-10713). BootHole has a high CVSS score of 8.2. 

Secure Boot is meant to protect the boot process from malicious code. It uses cryptographic signatures to verify each piece of code as needed during the boot process; it also includes the ability to sign bootloaders from non-Microsoft operating systems. Grand Unified Bootloader (GRUB) is the bootloader that loads and transfers control to the OS in most Linux distributions.

While GRUB2 is the primary bootloader for modern Linux distros, this bug affects systems using Secure Boot even if they're not using GRUB2. This issue also extends to Windows devices using Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority, meaning most laptops, desktops, servers, and workstations are affected, along with network appliances and equipment used in the industrial, healthcare, and finance sectors, the researchers report.

"The purpose of Secure Boot was to lock it down to just the signed images," says John Loucaides, vice president of research and development at Eclypsium. "Since this issue is in a signed bootloader, you can drop it on any system running Secure Boot and it would bypass that protection."

BootHole is a buffer overflow vulnerability that exists in the way that GRUB2 parses content from the GRUB2 configuration file. The GRUB2 config file is a text file and usually isn't signed like other files and executables. As a result of this flaw, an attacker could change the contents of the GRUB2 config file to ensure malicious code is run before the OS is loaded.

This attack would require elevated privileges or physical access to a system where Secure Boot is configured to trust the Microsoft UEFI CA. An attacker could install an affected GRUB bootloader to gain even higher privileges and persist on the device. Successful exploitation would let an attacker disable future code integrity checks, allowing more executables and drivers to be loaded. They would have control over the device's OS, applications, and data. 

The attack would work even if Secure Boot is enabled and properly verifying signatures on all loaded executables, researchers report. 

A Complex Fix to a Complex Problem
In a technical write-up of the vulnerability, Eclypsium reports all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable, with the exception of one bootable tool vendor that added custom code for signature verification.

"As such, this will require the release of new installers and bootloaders for all versions of Linux," researchers said. "Vendors will need to release new versions of their bootloader shims to be signed by the Microsoft 3rd Party UEFI CA."

Eclypsium coordinated today's disclosure with OS vendors, manufacturers, and CERTs. New bootloaders will need to be signed and deployed; vulnerable ones should be revoked to prevent adversaries from using older versions in an attack. Companies expected to push advisories and/or updates today include Microsoft, UEFI Security Response Team, Oracle, Red Hat, Canonical, SuSE, Debian, Citrix, VMware, and various OEMs and software vendors.

Until all affected versions are added to the dbx revocation list, an attacker will be able to use a vulnerable version of shim and GRUB2 to target a system – meaning every device that trusts the Microsoft Third Party UEFI CA will be exposed until then. Some OEMs that control both the hardware and software stacks in their devices use their own key to sign GRUB2. They will need to provide updates and revocation of vulnerable versions of GRUB2 for their systems as well.

"It's sort of bad when fixing the problem is a problem, and this is one of those instances," says Loucaides of the complexity of patching BootHole. This issue will require admins of affected devices to update installed versions of operating systems as well as installed images, including disaster recovery media. They will also need to coordinate: If the revocation list is updated before a given Linux bootloader and shim, the OS will not load. Before revocation updates are pushed across an enterprise, recovery and installation media must be updated.  

"That sort of complication is what I try to highlight for folks, especially with a large IT department and one team isn't consulting with the other team when they deploy these updates," says Loucaides. Having all of these updates out at once will require a lot of manual testing on the part of administrators, and it's expected this will be a lengthy process. 

In response to Eclypsium's initial report, Canonical researchers looked at GRUB2 with greater scrutiny and found additional vulnerabilities. An industrywide effort is underway to identify and fix more vulnerabilities that don't yet have individual CVEs assigned.

Related Content:

Register now for this year's fully virtual Black Hat USA, scheduled to take place August 1–6, and get more information about the event on the Black Hat website. Click for details on conference information and to register.