A flaw in the GRUB2 bootloader affects most Linux devices and some Windows computers using UEFI Secure Boot.
A newly discovered vulnerability in the GRUB2 bootloader, dubbed BootHole, may threaten Linux and Windows machines using Secure Boot. Attackers who exploit it could interfere with the boot process that precedes starting up the actual operating system (OS).
This process relies on components known as bootloaders that are responsible for loading the firmware of all computer hardware components on which the actual OS runs.
BootHole is a vulnerability in GRUB2, one of today's most popular bootloader components. Currently, 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.
What is the issue?
Researchers say BootHole allows attackers to tamper with the GRUB2 component to insert and execute malicious code during the boot-loading process, effectively allowing attackers to plant code that has full control of the OS, launched at a later point.
This type of malware is usually known as a bootkit because it lives inside bootloaders, in the motherboard physical memory, in locations separate from the actual OS, allowing it to survive OS reinstalls.
The BootHole vulnerability was discovered earlier this year by security researchers from Eclypsium. The actual full technical details about the bug have been published on the Eclypsium blog.
According to Eclypsium, the actual BootHole vulnerability is 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.
How to fix the BootHole vulnerability
We still seem to be a long way from fully fixing CVE-2020-10713. Simply installing patches containing updated GRUB2 bootloader will not fix BootHole, since attackers will be able to replace the device's existing bootloader with a different, vulnerable version.
According to Eclypsium, “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.”
Fixing BootHole requires a multi-stage mitigation process that could take years for organizations to complete.
See if you are vulnerable to BootHole
Use these Powershells and bash scripts from Eclypsium to detect if bootloaders that are being revoked by this dbxupdate.
Vendors Security Advisories for BootHole
While the fully fixing this vulnerability remains to be out of sight for the time being, here are some vendor’s advisories for CVE-2020-0713 that could mitigating the risk until the vulnerability be fully fixed:
Here's a list for all advisories:
Reference
* https://thehackernews.com/2020/07/grub2-bootloader-vulnerability.html?m=1
* https://ubuntu.com/security/notices/USN-4432-1
* https://access.redhat.com/security/vulnerabilities/grub2bootloader
* https://www.securityweek.com/companies-respond-boothole-vulnerability