BootHole is a new vulnerability in the GRUB2 bootloader used by most Linux distributions. The vulnerability, CVE-2020-10713, can be exploited for arbitrary code execution during the boot process, even with Secure Boot enabled.
If exploited successfully, the vulnerability could give attackers the opportunity to install persistent and stealthy bootkits or malicious bootloaders. Once installed, these could give attackers nearly full control over compromised devices, Eclypsium researchers warn.
Systems Affected by the BootHole (CVE-2020-10713) vulnerability
It is noteworthy that the vulnerability affects systems using Secure Boot, even in case they are not using GRUB2. Nearly all signed versions of GRUB2 are prone to the attack, which means that “virtually every Linux distribution is affected“. Furthermore, GRUB2 supports other operating systems, kernels, and hypervisors such as Xen, the researchers warn in their report.
The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority. Thus the majority of laptops, desktops, servers and workstations are affected, as well as network appliances and other special purpose equipment used in industrial, healthcare, financial and other industries. This vulnerability makes these devices susceptible to attackers such as the threat actors recently discovered using malicious UEFI bootloaders.
It also turns out that the boot process is extremely important for the security of any device. The boot process is associated with firmware that controls the way the device’s components operate. It also coordinates the loading of the operating system. “In general, the earlier code is loaded, the more privileged it is,” the report notes.
What about Secure Boot?
Secure Boot, in particular, utilizes cryptographic signatures to verify the integrity of each piece of code, because it is needed during the boot process. Two critical databases are involved in this process: “the Allow DB (db) of approved components and the Disallow DB (dbx) of vulnerable or malicious components, including firmware, drivers, and bootloaders.”
q Access to modify these databases is protected by a Key Exchange Key (KEK), which in turn is verified by a Platform Key (PK). Although the PK is used as a root of trust for updates to the platform, it’s not expressly part of the boot process (but is shown below for reference). It is dbx, db, and KEK that are used to verify the signatures for loaded executables at boot time.
The BootHole (CVE-2020-10713) vulnerability
In short, the flaw is of the buffer overflow type, and it occurs in GRUB2 when parsing the grub.cfg file. “This configuration file is an external file commonly located in the EFI System Partition and can therefore be modified by an attacker with administrator privileges without altering the integrity of the signed vendor shim and GRUB2 bootloader executables,” the researchers explain.
The buffer overflow enables attackers to carry out arbitrary code execution within the UEFI execution environment. This could then be exploited to run malware, alter the boot process, directly patch the OS kernel, or perform a range of other malicious actions.
The researchers say they will update the information available in their report once more is known. They also encourage users and admins to watch carefully for alerts and notifications from their hardware vendors and relevant open-source projects.
In March this year, security researchers discovered a 17-year-old remote code execution bug that impacts the PPP daemon software (pppd) in nearly all Linux operating systems. The PPP daemon comes installed on a wide range of Linux distros, and it also powers the firmware of a range of networking devices. The RCE vulnerability, CVE-2020-8597, was discovered by IOActive security researcher Ilja Van Sprundel.