Billions of Devices Impacted by Secure Boot Bypass

Billions of Windows and Linux devices are vulnerable to cyberattacks stemming from a bug in the GRUB2 bootloader, researchers are warning.

GRUB2 (which stands for the GRand Unified Bootloader version 2) is the default bootloader for the majority of computing systems. Its job is to manage part of the start-up process – it either presents a menu and awaits user input, or automatically transfers control to an operating system kernel.

Secure Boot is an industry standard that ensures that a device boots using only trusted software. When a computer starts, the firmware checks the signatures of UEFI firmware drivers, EFI applications and the operating system. If the signatures are valid, the computer boots, and the firmware gives control to the operating system. According to Eclypsium researchers, the bug tracked as CVE-2020-10713 could allow attackers to get around these protections and execute arbitrary code during the boot-up process, even when Secure Boot is enabled and properly performing signature verification.

Dubbed BootHole by Eclypsium because it opens up a hole in the boot process, the new bug is a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg), according to Eclypsium.

“The GRUB2 config file is a text file and typically is not signed like other files and executables,” researchers wrote in the firm’s analysis, released on Wednesday. As a result, Secure Boot doesn’t check it. Thus, an attacker could modify the contents of the GRUB2 configuration file to include attack code. And further, that file is loaded before the operating system is loaded, so the attack code runs first.

“In this way, attackers gain persistence on the device,” explained researchers.

On the technical front, Red Hat noted that the grub.cfg file is composed of several string tokens.

“The configuration file is loaded and parsed at GRUB initialization right after the initial boot loader, called shim, has loaded it,” the project said in an advisory issued on Wednesday. “During the parser stage, the configuration values are copied to internal buffers stored in memory. Configuration tokens that are longer in length than the internal buffer size end up leading to a buffer overflow issue. An attacker may leverage this flaw to execute arbitrary code, further hijacking the machine’s boot process and bypassing Secure Boot protection. Consequently, it is possible for unsigned binary code to be loaded, further jeopardizing the integrity of the system.”

Once in, attackers have “near total control” over a target machine: “Organizations should be monitoring their systems for threats and ransomware that use vulnerable bootloaders to infect or damage systems,” according to the analysis.

The bug carries a high-severity CVSS rating of 8.2 (Red Hat deems it “moderate” in severity, and Microsoft characterizes it as “important”). BootHole likely avoided a critical rating because in order to exploit it, an attacker would need to first gain administrative privileges.

“An attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a networked system with root access,” according to Red Hat.

The bad news is that GRUB2 is nearly ubiquitous across the computing landscape.

“The vulnerability is in the GRUB2 bootloader utilized by most Linux systems,” the researchers said. “The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.”

They added that the majority of computers (laptops, desktops, servers and workstations) are vulnerable, and that the vulnerability also affects network appliances, proprietary gear specific to healthcare, financial and other verticals, internet-of-things (IoT) devices, and operational technology (OT) and SCADA equipment in industrial environments. In all, billions of devices are susceptible.

Worse, no simple patch or firmware update can fix the issue, according to Eclypsium.

“Mitigation is complex and can be risky and will require the specific vulnerable program to be signed and deployed, and vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack,” the researchers said. “The three-stage mitigation process will likely take years for organizations to complete patching.”

On the supplier side, the fix will require the release of new installers and bootloaders for all versions of Linux, as well as new versions of vendors’ “shims” (the aforementioned first-stage boot loaders) to be signed by the Microsoft Third-Party UEFI certificate authority, Eclypsium warned. Also, hardware-makers that provision their own keys into their hardware at the factory level (which sign GRUB2 directly) will need to provide updates, and revoke their own vulnerable versions of GRUB2.

“It is important to note that until all affected versions are added to the [Secure Boot revocation list, a.k.a. dbx], an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system,” researchers explained. “This means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time.”

Eclypsium has coordinated responsible disclosure of BootHole with a raft of affected vendors and Linux distros, including Microsoft, the UEFI Security Response Team (USRT), Oracle, Red Hat (Fedora and RHEL), Canonical (Ubuntu), SuSE (SLES and openSUSE), Debian, Citrix, VMware, and various OEMs and software vendors, several of which have issued their own advisories.

Microsoft will be releasing a set of signed dbx updates, which can be applied to systems to block shims that can be used to load the vulnerable versions of GRUB2, according to Eclypsium.

“Due to the risk of bricking systems or otherwise breaking operational or recovery workflows, these dbx updates will initially be made available for interested parties to manually apply to their systems rather than pushing the revocation entries and applying them automatically,” the firm noted. “Organizations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems.”

Organizations should also test device-recovery capabilities, including the “reset to factory defaults” functionality, so they can recover it if a device is negatively impacted by an update.

Complimentary Threatpost Webinar: Want to learn more about Confidential Computing and how it can supercharge your cloud security? This webinar “Cloud Security Audit: A Confidential Computing Roundtable” brings top cloud-security experts together to explore how Confidential Computing is a game changer for securing dynamic cloud data and preventing IP exposure. Join us  Wednesday Aug. 12 at 2 p.m. ET for this FREE live webinar.