A serious vulnerability named BootHole has been discovered in the bootloader GRUB2. Millions of systems are at risk of being exposed to hackers, mainly those running Linux, but Windows is also affected. Discovered by security researchers at Eclypsium, the BootHole vulnerability has been assigned CVE-2020-10713 (“GRUB2: The designed grub.cfg file can lead to arbitrary code execution during the boot process”) and a CVSS rating of 8.2.
The flaw can be exploited to get 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 making use of Secure Boot with the standard Microsoft Third-Party UEFI Certification Authority open to attack.
See also:
Eclypsium says the magnitude of the vulnerability is such that “most laptops, desktops, servers and workstations are affected, as well as network devices and other special-purpose equipment used in industrial industries, from health, financial and otherwise. ” BootHole has been known for quite some time, but security researchers helped coordinate responsible vulnerability disclosure so that operating system developers, software engineers, and others work together to create solutions.
Despite this, Eclypsium still cautions that: “Mitigation will require new bootloaders to be signed and implemented, and vulnerable bootloaders must be revoked to prevent adversaries from using older and more vulnerable versions in an attack. This It will probably be a long process and it will take considerable time for organizations to complete the patches. “
Writing about the vulnerability, the security company explains:
In the course of Eclypsium analysis, we have identified a buffer overflow vulnerability in the way that GRUB2 parses the contents of the GRUB2 configuration file (grub.cfg). Note: The GRUB2 configuration file is a text file and is generally not signed like other files and executables. This vulnerability allows the execution of arbitrary code within GRUB2 and therefore control over the startup of the operating system. As a result, an attacker could modify the contents of the GRUB2 configuration file to ensure that the attack code is executed before loading the operating system. 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 privilege escalation and persistence on the device, even with Secure Boot enabled and successfully performing signature verification on all loaded executables. One of the explicit design goals of Secure Boot is to prevent unauthorized code, even with administrator privileges, from gaining additional privileges and pre-operating system persistence by disabling Secure Boot or modifying the boot chain.
With the only exception of a startup tool provider that added custom code to perform a signature verification of the grub.cfg configuration file in addition to the signature verification performed on the GRUB2 executable, all versions of GRUB2 that load commands from an external grub.cfg The configuration file is vulnerable. As such, this will require the release of new installers and boot loaders for all versions of Linux. Suppliers will be required to release new versions of their bootloader boots to be signed by Microsoft’s third-party UEFI CA. It is important to note that until all affected versions are added to the dbx revocation list, an attacker could use a vulnerable version of shim and GRUB2 to attack the system. This means that each device that relies on Microsoft’s third-party UEFI CA will be vulnerable during that time period.
In addition to vendors using wedges signed by Microsoft’s third party UEFI CA, some original equipment manufacturers that control both the hardware and the software stack on their devices use their own hardware-supplied key at the factory to sign GRUB2 directly . They must also provide updates and revocation of previous vulnerable versions of GRUB2 for these systems.
Microsoft, the UEFI Forum, Debian, Canonical, RedHat, SUSE, HP, HPE, VMware and the Upstream Grub2 project have released advisory notices.
Since updates and fixes are likely to take a long time to implement, there are a few tips in the meantime:
- Immediately start monitoring the contents of the boot loader partition (EFI system partition). This will save time for the rest of the process and help identify the affected systems in your environment. For those who have implemented the Eclypsium solution, you can see this monitoring in the “MBR / Bootloader” component of a device.
- Continue to install operating system updates as usual on desktop computers, laptops, servers, and devices. Attackers can take advantage of privilege escalation flaws in the operating system and applications to exploit this vulnerability, so preventing them from gaining administrative level access to their 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, business gold images, virtual machines, or other bootable media.
- Test updating the revocation list. Be sure to specifically test the same firmware versions and models that are used in the field. It may be helpful to upgrade to the latest firmware first to reduce the number of test cases.
- To close this vulnerability, you must implement the revocation update. Make sure all boot devices have received operating system updates first, slowly roll them out to a small number of devices at a time, and incorporate lessons learned from testing as part of this process.
- Contact your third-party vendors to validate that they know and address this issue. They must provide you with an answer as to their applicability to the services / solutions they provide, as well as their plans to remedy this highly rated vulnerability.
Image credit: Bhimrao Patil / Shutterstock
