‘BootHole’- A GRUB2 and Secure boot vulnerability affecting Windows and Linux Systems

boothole

Cybersecurity researchers found a critical high-risk vulnerability in GRand Unified Bootloader version 2(GRUB2), a popular bootloader. The vulnerability affects all systems including virtual machines, IoT devices, workstations running in Windows, Linux. The vulnerability is exploited using buffer overflow to bypass secure boot to compromise the OS

Codenamed as ‘BootHole’ and tracked as CVE-2020-10713, The vulnerability is a type of a bootkit which lives in bootloader components and can run every time the operating system boot up compromising the machine to a high level risk by neglecting Secure Boot feature.

Secure Boot is a security feature of the Unified Extensible Firmware Interface (UEFI) that uses a bootloader to load critical components, peripherals, and the operating system while ensuring that only cryptographically signed code executes during the boot process.

BootHole tampers the grub.cfg, a configuration file separate from the actual GRUB2 component, from where the bootloader pulls system-specific settings so 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.

The vulnerability is found by CyberSecurity research group Eclypsium and says BootHole can be (ab)used to tamper with the bootloader, or even replace it with a malicious or vulnerable version including workstations and servers with secure boot enabled.


Secure Boot vs Malicious Boot(Image: Eclysium)

Eclypsium says that the attacker needs admin access in order to tamper with the grub.cfg file. This looks like a limitation, but in reality, it is not. Operating systems and their components are littered with “elevation of privilege” bugs that could be exploited as part of a BootHole attack chain to let malware gain admin access and modify grub.cfg.

Eclypsium warned “However, full deployment of this revocation process will likely be very slow. UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim are updated, then the operating system will not load.”

According to EclypsiumFull 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.

The Advisories that already released patches are

Download the PDF report(from Eclypsium)

Credits:All images are from Eclypsium

Leave a Reply

Your email address will not be published. Required fields are marked *