The BootHole and related vulnerabilities raise the question of whether software used for critical security functions should have special scrutiny. When a security operation fails the ramifications are considerable, especially when the security process is widely distributed. A critical vulnerability found in the OpenSSL library is an example and BootHole.

What is BootHole Vulnerability?

The BootHole vulnerability was discovered by Eclypsium in April 2020. It took nearly four months to remediate because many stakeholders were involved. The Eclypsium researchers found a buffer overflow in GRUB2 (GRand Unified Bootloader version 2), which is the default bootloader in most Linux OS distributions. Gaining control of a bootloader is an ultimate prize for attackers (and their malware) because it provides persistent access to a device.

How do attackers exploit the vulnerability?

“BootHole is especially dangerous because it allows for the bypassing of Secure Boot, which is designed to ensure the integrity of the boot process by controlling which software can boot on a device through signature validation,” .When weaponized, this vulnerability affords attackers complete control of the operating system, allowing them to load executables and drivers and bypass security measures such as anti-virus software.

The interface between an operating system and platform firmware is standardized in the Unified Extensible Firmware Interface (UEFI) specification. This function is of keen interest to hackers. BootHole is vulnerability, but 2018 ESET researchers identified a rootkit attacking UEFI bootloading in the wild. Previously these rootkits were discussed in theory, but LoJax, the name given to the malware, was an actual cyberattack. Ironically, this discovery encouraged Microsoft and its hardware partners to work toward improving on Secure Boot.

Security Software Requires Additional Scrutiny

LoJax and BootHole is that software security features fall victim to coding errors just as all software does. “One line of code was all that was required to negate Secure Boot,”

Eclypsium’s initial report uncovering the BootHole GRUB2 buffer overflow vulnerability, many industry contributors including those at Microsoft, Canonical and Debian conducted deep examinations of GRUB2 security and discovered eight additional GRUB2 vulnerabilities (CVE-2020-14308, CVE-2020-14309, CVE-2020-14310, CVE-2020-14311, CVE-2020-15705, CVE-2020-15706, CVE-2020-15707, CVE-2020-7205) and two Linux kernel flaws (CVE-2019-20908, CVE2020-15780). Those new bugs were of medium severity while BootHole was of high severity. The discovery illustrates that when you closely scrutinize software, you will find more errors.

The situation was summed up well by Maxwell Dulin, “It is extremely difficult to build secure firmware and software. Code that has a major impact on the security of the system needs to be under the eyes of many investigators and researchers in order to be confident in the security of the product. Otherwise, there is a high likelihood that a huge hole exists that can allow malicious parties to compromise the system.”

Security features need to be more robust and it is possible if additional effort is afforded to security elements. All versions of GRUB2, apart from one, were vulnerable if they loaded commands from an external grub.cfg configuration file. The sole exception was because one bootable tool vendor incorporated custom code for signature verification.

On Aug. 3 a number of major technology vendors announced the creation of the Open Source Security Foundation (OpenSSF). This collaborative foundation provides security researchers with a mechanism to address improving the security of open source software.  According to the group’s FAQ, the OpenSSF “will start with a focus on metrics, tooling, best practices, developer identity validation and vulnerability disclosures best practices

Recommendations

It is recommended to consider the following best practices:

• Mitigating the BootHole vulnerability required coordination among many parties, including Linux distribution vendors, open source maintainers and hardware OEM. This large community updated bootloaders, installers and shims.
• The components had to be signed by Microsoft, which is the designated certificate signer. The nature of the vulnerability does not allow for a single patch; rather, fully mitigating BootHole requires multiple steps that must be completed in a specific order.
• The new alternative is “secured-core” PCs, combining virtualization, operating system, hardware and firmware safeguards to protect systems against rootkits and firmware-based attacks.
• Updates to GRUB2 to address the vulnerability.
• Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims.
• Administrators of affected devices will need to update installed versions of operating systems in the field as well as installer images, including disaster recovery media.
• Eventually the UEFI revocation list (dbx)needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.