Details published by Eclypsium on July 29, 2020, revealed a discovery by Eclypsium researchers, Mickey Shkatov and Jesse Michael on a vulnerability — dubbed “BootHole” — in the GRUB2 bootloader utilized by most Linux systems. GRUB2 is used as the primary bootloader for all major Linux distros, but it can also boot and is sometimes used for Windows, macOS, and BSD-based systems as well.
The vulnerability can be used to gain arbitrary code execution during the boot process, even when Secure Boot is enabled. Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device.
Challenges of Secure Boot and how boothole works.
According to the researchers, Secure Boot is not without its potential problems, as with any technical process. The process involves many pieces of code, and a vulnerability in any one of them presents a single point of failure that could allow an attacker to bypass Secure Boot. Additionally, a vulnerability in the boot process that enables arbitrary code execution can allow attackers to control the boot process and operating system, even when secure boot signatures are verified.
Attackers can also use a vulnerable bootloader against the system. For example, if a valid bootloader was found to have a vulnerability, a piece of malware could replace the device’s existing bootloader with the vulnerable version. The bootloader would be allowed by Secure Boot and give the malware complete control over the system and OS. Mitigating this requires very active management of the dbx database used to identify malicious or vulnerable code.
The image below shows a simplified explanation of the BootHole attack vulnerability, located inside grub.cfg, a configuration file separate from the actual GRUB2 component, from where the bootloader pulls system-specific settings. Eclypsium says that attackers can modify values in this file to trigger a buffer overflow inside the GRUB2 component when it reads the file on every OS boot.
(You can read more from Eclypsium blog to get the full technical details.)
Eclypsium says full mitigation of this issue will require coordinated efforts from a variety of entities: affected open-source projects, Microsoft, and the owners of affected systems, among others. This will include:
- Updates to GRUB2 to address the vulnerability.
- Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims.
- New shims will need to be signed by the Microsoft 3rd Party UEFI CA.
- 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.
They also said that they expect security alert and patches from:
- UEFI Security Response Team (USRT)
- Red Hat (Fedora and RHEL)
- Canonical (Ubuntu)
- SuSE (SLES and openSUSE)
- Various OEMs
- Software vendors, including security software, are also impacted by this vulnerability and will be updating their bootloaders.