An annoying vulnerability in the widely used GRUB2 bootloader can be potentially exploited by malware or a rogue insider already on a machine to thoroughly compromise the operating system or hypervisor while evading detection by users and security tools.
This affects mainly Linux-based computers and devices, where GRUB2 is deployed a lot, though boxes running Windows can be potentially roped in, too. Any system on which GRUB2 can be installed and run at boot-time is potentially vulnerable.
Designated CVE-2020-10713, the vulnerability allows a miscreant to achieve code execution within the open-source bootloader, and effectively control the device at a level above the firmware and below any system software. Bug hunters at Eclypsium, who found the flaw and dubbed it BootHole, said patching the programming blunder will be a priority and a headache for admins.
To be clear, malware or a rogue user must already have administrator privileges on the device to exploit the flaw, which for the vast majority of victims is a game-over situation anyway. You've likely lost all your data and network integrity at that point. What this bootloader bug opens up is the ability for a determined miscreant to burrow deeper, run code at a low level below other defenses, and compromise the foundation of a system to the point where they cannot be easily detected by administrators nor antivirus.
The flaw itself is a classic exploitable heap buffer overflow during the parsing of the
grub.cfg configuration file by GRUB2 during startup. GRUB2 is used by Linux distributions to load the operating system from storage after power on or reset, though it can be used to load other OSes as well as hypervisors and similar stuff.
Should an attacker be able to trigger the buffer overflow flaw, by poisoning the configuration file to achieve code execution during the next reboot or power up, they can potentially sidestep defenses and install a bootkit on the computer or device, paving the way for hidden cryptominers, spyware, backdoors, and so on. This code execution would occur in the context of the bootloader, which has effectively free rein over the computer.
"Today, you could bypass some of the hypervisor protections that are used in enterprises to protect credentials, or bypass protections on encryption process," Eclypsium VP of research and development John Loucaides told The Register. "You could also persist there in a place that most security tools are not looking."
Blown away ... Eclypsium's illustration of the GRUB2 heap buffer overflow exploitation, which can lead to arbitrary code execution in the context of the bootloader. Tap to enlarge
Eclypsium stressed that for miscreants, this is a means of achieving persistence on an already-pwned machine, or loading it with a data-deleting time bomb, rather than hijacking a box over the network or internet. Interestingly, although GRUB2 is primarily associated with Linux, this vulnerability can be exploited on machines running Windows and other system software, we're told. Highly privileged malware or rogue insiders could in theory install a vulnerable version of GRUB2 on a box, and configure the Secure Boot firmware to run it on startup, thus triggering low-level code execution prior to loading the OS.
The fix, it is said, is performed in two parts. The first involves patching the heap buffer overflow, and is rather straightforward: update GRUB2, either from source or via your operating system's software upgrade mechanism.
The second part of the update process is a bit more tricky. To prevent a privileged attacker from simply downgrading the updated GRUB2 to a vulnerable version and exploiting it on a Secure Boot system, the firmware must be banned from executing these vulnerable out-of-date builds. That will involve installing new so-called vendor shims, which verify and execute the bootloader during startup; these new shims will prevent the execution of out-dated GRUB2 versions. Eventually, the old versions will end up in Secure Boot revocation lists, preventing the builds from running.
Flowchart ... Eclypsium's illustration of the process to downgrade GRUB2 to a vulnerable version to exploit. Tap to enlarge
In other words, look out for and install security updates for GRUB2 and your Secure Boot process from your OS and hardware makers. You can get more information from Microsoft, Debian, Canonical, Red Hat, SUSE, HP, and VMware. ®