Recently disclosed vulnerability in GRUB2 bootloader dubbed “BootHole” could allow an attacker to gain silent malicious persistence by attacking the GRUB2 config file, grub.cfg.
Background
On July 29, researchers at Eclypsium disclosed a high severity vulnerability in the GRand Unified Bootloader (GRUB) version 2. Dubbed “BootHole,” the flaw affects the GRUB2 bootloader in Windows and Linux devices using Secure Boot.
Image Source: Eclypsium
Analysis
CVE-2020-10713 is a buffer overflow vulnerability in GRUB2, a piece of software that loads an Operating System (OS) into memory when a system boots up. The flaw exists due to the way GRUB2 parses a configuration file, grub.cfg. GRUB2 is the default boot loader for Red Hat Enterprise Linux (RHEL) and many other *nix distributions.
Unified Extensible Firmware Interface (UEFI) Secure boot is a verification mechanism for ensuring that code launched by firmware is trusted. Normally, Secure Boot verifies the integrity of a file by checking its signature against known keys. However, the grub.cfg in the GRUB2 boot loader is not signed, and therefore not checked by Secure Boot. By specially modifying this file, an attacker could gain a form of persistent exploitation past the point of boot, which is the exact thing that Secure Boot is meant to prevent.
It is important to note that successful exploitation of this vulnerability would require an attacker to have administrator or elevated privileges, or local access to a vulnerable device, which limits the impact of this vulnerability.
Extension of previous GRUB research
BootHole is actually an extension of research into Secure Boot bypass previously conducted by Yuriy Bulygin and Alex Bazhaniuk, founders and CEO and CTO respectively of Eclypsium, and security researcher Andrew Furtak.
New GRUB vulnerability: https://t.co/sQAmq5a3ip
— Alex Bazhaniuk (@ABazhaniuk) July 29, 2020
A new iteration on our 2013 secure boot bypass (https://t.co/MYtjlful2R): In addition to implementation flaws, this overflow in GRUB2 affects almost every UEFI Secure Boot system and shows a systemic issue that is very hard to fix. pic.twitter.com/ioaJQN4O4M
More Vulnerabilities Unearthed by Canonical
After Eclypsium disclosed BootHole to multiple vendors, Canonical’s security team did their own research into potential new vulnerabilities in GRUB2, and discovered the following flaws:
| CVE | Vulnerability Type | CVSSv3 Score (Severity) |
|---|---|---|
| CVE-2020-14308 | Buffer overflow | 6.4 (Medium) |
| CVE-2020-14309 | Heap based overflow | 5.7 (Medium) |
| CVE-2020-14310 | Heap based overflow | 5.7 (Medium) |
| CVE-2020-14311 | Heap based overflow | 5.7 (Medium) |
| CVE-2020-15705 | Unsigned kernel load | 6.4 (Medium) |
| CVE-2020-15706 | Use-after-free | 6.4 (Medium) |
| CVE-2020-15707 | Integer overflow | 5.7 (Medium) |
A larger effort investigation was conducted by multiple security teams from Oracle, Red Hat, Canonical, VMware and Debian which identified several additional vulnerabilities in the code base which have not yet received individual CVE numbers.
Affected Vendors
Eclypsium’s advisory notes the following vendors are confirmed to be affected by BootHole, and as new affected vendors are identified, the list will be updated on its advisory page:
Proof of concept
At the time this blog post was published, there was no proof of concept code to demonstrate exploitation against a target. However, the Eclypsium team has released scripts to help administrators scan and identify certificates revoked by different OS vendors as part of the security updates for CVE-2020-10713.
Solution
Eclypisum mentions that addressing this vulnerability will involve a multi-step process that is not a normal patch style fix. This process includes:
- Vendors providing updates to GRUB2 to fix and secure the bootloader
- Microsoft’s 3rd party UEFI Certificate Authority will need updates to their certificates
- Organizations will then need to update their affected hosts and potential backups as well.
Microsoft has released an advisory with instructions on applying an untested patch to the Secure Boot DBX (the forbidden signature database) to include the vulnerable modules that Microsoft has revoked, blocking these modules from loading even if compromised. Windows hosts are only vulnerable if the host’s Unified UEFI Certificate Authority (CA) trusts third party certificates.
As this process will require coordinated effort from multiple vendors, we expect patches to slowly be released over time, and may not be available for all platforms immediately.
Identifying affected systems
A list of Tenable plugins to identify this vulnerability will appear here as they’re released.
Get more information
Join Tenable's Security Response Team on the Tenable Community.
Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.
Get a free 30-day trial of Tenable.io Vulnerability Management.