GRUB2, one of the world’s most widely used programs for booting computers, has a vulnerability that can make it easier for attackers to run malicious firmware during startup, researchers said on Wednesday. This would affect millions or possibly hundreds of millions of machines. While GRUB2 is primarily used on Linux computers, attacks that exploit the vulnerability can also be performed on many Windows PCs.
The vulnerability, discovered by researchers at security firm Eclypsium, poses another serious threat to UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that a manufacturer’s software is reliable. Secure Boot was designed to prevent attackers from hijacking the boot process by replacing the desired software with malicious software.
Stealthier, more powerful and difficult to disinfect
So-called bootkits are among the most serious types of infections because they run at the lowest level of the software stack. That allows malware to be more stealthy than most malware, survive OS reinstallations and bypass security protections built into the operating system.
Boot Hole, as the researchers have named the vulnerability, stems from a buffer overflow in the way GRUB2 parses text in grub.cfg, the main configuration file for the boot loader. By adding long text strings to the file, attackers can overload the allocated memory space for the file and cause the malicious code to spill into other parts of memory, where it then runs.
The configuration file is not digitally signed, so Secure Boot will not detect when it has been maliciously modified. GRUB2 also does not use address space layout randomization, data execution prevention, and other exploit protections that are standard on operating systems. These omissions make it trivial for attackers who already have a foothold on the target computer to exploit the flaw. From there, they can completely avoid protection that many people expect to prevent bootkits from taking hold.
In addition to the Eclypsium report, Debian provides a solid overview here.
But there are some important catch
However, the severity of the vulnerability is offset by a few things. First, the attacker must have administrative rights to the computer or physical access to the machine. Control at the administrator level is increasingly difficult to obtain in modern operating systems due to the great advances they have made to block vulnerabilities. Physical access may be easier during border crossings or similar times when a user briefly loses physical possession of a computer. But the requirement is abrupt in most other scenarios, so many users are unlikely to be affected. Furthermore, physical possession greatly restricts the scalability of attacks.
Two other factors that make Boot Hole less scary: Attackers who already have administrative or physical control over a computer already have plenty of other ways to infect it with advanced and stealth malware. Additionally, there are several other known techniques to prevent safe startup.
“I would say that Secure Boot is not the basis of PC security today, because it is rarely effective, and for its [Eclypsium’s] According to our own claim, it has been easy to avoid this for over a year, with no long-term solution in sight, ”HD Moore, vice president of research and development at Atredis Partners and an expert in software exploitation, told me. “I’m not sure what buffer overflow is useful for in GRUB2, as there are other problems if the grub.cfg is not signed. “It can be useful as a malware vector, but still, there is no reason to exploit a buffer overflow when you can use a custom grub.cfg file to chain load the real operating system.”
Other researchers seem to agree with the assessment. CVE-2020-10713, as the vulnerability is tracked, has a severity rating of “Moderate.”
The Eclypsium claim that Moore was referring to involves a revocation in February of a boot loader security company that Kaspersky Lab used on a rescue disk to start disabled computers. The revocation caused so many problems that Microsoft, which oversees the validation process, withdrew the change. The revocation underscores not only the difficulty of patching flaws like Boot Hole (more on that later) but also the fact that Secure Boot can already be circumvented.
It’s not scary doesn’t mean it’s not serious
The obstacles and limitations of exploitation do not mean that vulnerability is not worth taking seriously. Secure Boot was created precisely for the stage required to exploit Boot Hole. The risk is compounded by the number of computer and software manufacturers affected. Eclypsium has a more complete list of those affected. They are:
- Microsoft
- The Unified Extensible Firmware Interface Forum
- Oracle
- Red Hat (Fedora and RHEL)
- Canonical (Ubuntu)
- SuSE (SLES and openSUSE)
- Debian
- Citrix
- VMware
- Various computer manufacturers
- Software vendors, including security software
Another serious consideration is the challenge of sending updates that do not permanently prevent a machine from starting, a phenomenon often called “crash.” As the Kaspersky incident shows, the risk is real and can have serious consequences.
Fixing the mess is a mess in itself
Solutions involve a multi-step process that will not be trivial or, in many cases, fast. GRUB2 must first be updated to correct the vulnerability and then distributed to manufacturers or administrators of large organizations. There, engineers will need to thoroughly test the upgrade on each model of computer they support to make sure the machine doesn’t crash. Updates should be corrected for the machines that do so. Only then will the update be ready to install in general.
Even then, it will be trivial for attackers with the privileges described above to roll back GRUB2 to its vulnerable version and exploit the buffer overflow. Although Windows machines generally do not have GRUB2 installed, privileged attackers can usually install it. To close this gap, computer manufacturers will have to revoke cryptographic signatures that validate the previous version or the “shim” firmware that loads the previous version.
This step also carries the risk of brick machines. If the signatures are revoked before installing the GRUB2 version, or in the case of Windows machines, signatures for other startup components, before a comprehensive test, millions of computers are also at risk of being blocked.
To avoid this possibility, Microsoft, Red Hat, Canonical and other manufacturers of operating systems and hardware generally offer two-step solutions. First, the GRUB2 update will be released and only after it has been tested and deemed safe for installation. Then, after a period that can last for months, the signatures will be revoked. Only after completing the second step will the vulnerability be repaired.
Microsoft, which operates the certification authority that certifies UEFI firms that are duly authorized by manufacturers, issued the following statement:
We are aware of a vulnerability in the GRand Unified Boot Loader (GRUB), commonly used by Linux. To exploit this vulnerability, an attacker would need to have administrative privileges or physical access on a system where Secure Boot is configured to trust the Microsoft UEFI CA. We are working to complete validation and compatibility testing of a required Windows Update package.
A Microsoft spokesperson said the company will provide urgently needed IT managers with a “mitigation option to install an untested update.” At an unspecified time, the spokesperson said, Microsoft will launch a solution for general availability. Microsoft has published a knowledge base article here.
Warnings from other affected companies are too numerous to provide in the initial version of this article. For the time being, readers should consult the websites of the affected companies. This post will be updated later to provide links.
For now, there is no reason to panic. The strict requirements for vulnerabilities make the severity of this vulnerability moderate. And as already mentioned, Secure Boot is already vulnerable to other bypass techniques. That does not mean that there is no reason to take this vulnerability seriously. Patch it as fast as possible, but only after extensive testing, either by experienced users or affected software and OS manufacturers. In the meantime, don’t lose sleep.
