A “BootHole” bug could let cyber-attackers load malware, steal information & move laterally into corporate, OT, IoT & home networks.
Billions of Windows & Linux devices are vulnerable to cyber-attacks coming from a bug in the GRUB2 bootloader, researchers warn.
GRUB2 (which stands for the GRand Unified Bootloader version 2) is the default bootloader for most computing systems. Its job is to manage part of the start-up process. It either presents a menu & awaits user input, or automatically transfers control to an operating system kernel.
Trusted Software
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 & the operating system.
If the signatures are valid, the computer boots, & 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 & execute arbitrary code during the boot-up process, even when Secure Boot is enabled & 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.
Text File
“The GRUB2 config file is a text file & typically is not signed like other files & executables,” researchers wrote in the firm’s analysis, released on Wed. As a result, Secure Boot does not check it. Thus, an attacker could modify the contents of the GRUB2 configuration file to include attack code. 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.
Technically, Red Hat noted that the grub.cfg file is composed of several string tokens.
Configuration File
“The configuration file is loaded & parsed at GRUB initialisation right after the initial boot loader, called shim, has loaded it,” the project said in an advisory issued on Wed.
“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.
Flaw
An attacker may use this flaw to execute arbitrary code, further hijacking the machine’s boot process & 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 the target machine: “Organisations should be monitoring their systems for threats & ransomware that use vulnerable bootloaders to infect or damage systems,” says the analysis.
CVSS rating
The bug carries a high-severity CVSS rating of 8.2 (Red Hat deems it “moderate” in severity, & Microsoft characterizes it as “important”). BootHole likely avoided a critical rating because in order to exploit it, an attacker would need to 1st gain admin. 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.
However, the bad news is that GRUB2 is nearly commonplace across the computing landscape.
Linux
“The vulnerability is in the GRUB2 bootloader utilised by most Linux systems,” the researchers mentioned. “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 & workstations) are vulnerable, & that the vulnerability also affects network appliances, proprietary gear specific to healthcare, financial & other verticals, internet-of-things (IoT) devices, & operational technology (OT) and SCADA equipment in industrial environments.
In all, billions of devices are therefore susceptible.
No simple patch or firmware update can fix the issue, according to Eclypsium.
Mitigation
“Mitigation is complex & can be risky & will require the specific vulnerable program to be signed & deployed, & vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack,” the researchers added. “The 3-stage mitigation process will likely take years for organisations to complete patching.”
On the supplier side, the fix will require the release of new installers & bootloaders for all versions of Linux, as well as new versions of vendors’ “shims” (the mentioned 1st-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 & revoke their own vulnerable versions of GRUB2.
Secure Boot
“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 & 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.”
UEFI Security Response Team
Eclypsium has co-ordinated responsible disclosure of BootHole with a raft of affected vendors & Linux distros, including Microsoft, the UEFI Security Response Team (USRT), Oracle, Red Hat (Fedora & RHEL), Canonical (Ubuntu), SuSE (SLES & openSUSE), Debian, Citrix, VMware, & various OEMs & 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.
Workflows
“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 & applying them automatically,” the firm noted.
“Organisations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders & firmware & verifying UEFI configurations, including revocation lists, in their systems.”
Organisations 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.
