Huge BootHole flaw in GRUB2 bootloader leaves millions of Windows and Linux systems at risk from hackers

A serious vulnerability dubbed BootHole has been discovered in the GRUB2 bootloader. Millions of systems run the risk of being exposed to hackers -- primarily those running Linux, but Windows is also affected. Discovered by security researchers at Eclypsium, the BootHole vulnerability has been assigned CVE-2020-10713 ("GRUB2: crafted grub.cfg file can lead to arbitrary code execution during boot process") and a CVSS rating of 8.2.

The flaw can be exploited to gain arbitrary code execution during the boot process, even when Secure Boot is enabled and virtually all Linux distributions are affected. But more than this, the vulnerability also leaves Windows systems that make use of Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority open to attack.

See also:

• Microsoft Defender warns that CCleaner is a 'potentially unwanted application'... here's why
• Microsoft releases KB4559003 and KB4559004 to fix problems with File Explorer, LTE connectivity and more
• Microsoft previews new tool to control Windows 10 telemetry

Eclypsium says that the scale of the vulnerability is such that "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". BootHole has been know about for quite some time, but the security researchers helped to coordinated the responsible disclosure of the vulnerability to give operating system developers, software engineers and others to work together to create fixes.

Despite this, Eclypsium still warns that: "Mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack. This will likely be a long process and take considerable time for organizations to complete patching".

Writing about the vulnerability, the security firm explains:

In the course of Eclypsium’s analysis, we have identified a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg). Of note: The GRUB2 config file is a text file and typically is not signed like other files and executables. This vulnerability enables arbitrary code execution within GRUB2 and thus control over the booting of the operating system. As a result, an attacker could modify the contents of the GRUB2 configuration file to ensure that attack code is run before the operating system is loaded. In this way, attackers gain persistence on the device.

Such an attack would require an attacker to have elevated privileges. However, it would provide the attacker with a powerful additional escalation of privilege and persistence on the device, even with Secure Boot enabled and properly performing signature verification on all loaded executables. One of the explicit design goals of Secure Boot is to prevent unauthorized code, even running with administrator privileges, from gaining additional privileges and pre-OS persistence by disabling Secure Boot or otherwise modifying the boot chain.

With the sole exception of one bootable tool vendor who added custom code to perform a signature verification of the grub.cfg config file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg configuration file are vulnerable. As such, this will require the release of new installers and bootloaders for all versions of Linux. Vendors will need to release new versions of their bootloader shims to be signed by the Microsoft 3rd Party UEFI CA. It is important to note that until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system. This means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time.

In addition to vendors using shims signed by the Microsoft 3rd Party UEFI CA, some OEMs that control both the hardware and the software stack in their devices use their own key that is provisioned into the hardware at the factory to sign GRUB2 directly. They will need to provide updates and revocation of previous vulnerable versions of GRUB2 for these systems as well.

Advisory notices have been published by Microsoft, the UEFI Forum, Debian, Canonical, RedHat, SUSE, HP, HPE, VMware and the Upstream Grub2 project.

As the rollout of updates and fixes is likely to take quite some time, there is some advice in the meantime:

1. Right away, start monitoring the contents of the bootloader partition (EFI system partition). This will buy time for the rest of the process and help identify affected systems in your environment. For those who have deployed the Eclypsium solution, you can see this monitoring under the "MBR/Bootloader" component of a device.
2. Continue to install OS updates as usual across desktops, laptops, servers, and appliances. Attackers can leverage privilege escalation flaws in the OS and applications to take advantage of this vulnerability so preventing them from gaining administrative level access to your systems is critical. Systems are still vulnerable after this, but it is a necessary first step. Once the revocation update is installed later, the old bootloader should stop working. This includes rescue disks, installers, enterprise gold images, virtual machines, or other bootable media.
3. Test the revocation list update. Be sure to specifically test the same firmware versions and models that are used in the field. It may help to update to the latest firmware first in order to reduce the number of test cases.
4. To close this vulnerability, you need to deploy the revocation update. Make sure that all bootable media has received OS updates first, roll it out slowly to only a small number of devices at a time, and incorporate lessons learned from testing as part of this process.
5. Engage with your third-party vendors to validate they are aware of, and are addressing, this issue. They should provide you a response as to its applicability to the services/solutions they provide you as well as their plans for remediation of this high rated vulnerability.

Image credit: Bhimrao Patil / Shutterstock