GRUB2, one of the most widely used computer startup programs worldwide, has a vulnerability that could help attackers run malicious firmware on startup, researchers said on Wednesday. This would affect millions or possibly hundreds of millions of machines. While GRUB2 is primarily used on Linux computers, vulnerabilities that exploit the vulnerability can also be carried out on many Windows computers.
The vulnerability, discovered by researchers at security company Eclypsium, is another serious threat to UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that the software used at startup trusts the computer manufacturer. Secure Boot was developed to prevent attackers from misusing the boot process by replacing the intended software with malicious software.
Furtive, powerful and difficult to disinfect
Bootkits are one of the most serious types of infections because they run at the lowest level of the software stack. As a result, the malware can be used better than most other malware programs, survive the reinstallation of the operating system and circumvent the security protection integrated in the operating system.
Boot Hole, as the researchers called the vulnerability, is based on 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 overfill the space allocated for the file and transfer malicious code to other parts of the memory, where it is then executed.
The configuration file is not digitally signed, so Secure Boot does not recognize if it has been maliciously changed. GRUB2 also does not use address space layout randomization, data execution prevention, and other anti-exploit protection measures that are standard in operating systems. These omissions make it trivial for attackers who have already gained a foothold on the target computer to take advantage of the bug. From there, they can bypass any protection that many people expect to prevent bootkits from grabbing.
In addition to the Eclypsium report, Debian offers a solid overview here.
But there are some important catches
However, the severity of the vulnerability is offset by a few things. First, the attacker must have either administrative privileges on the computer or physical access to the computer. Control at the administrator level is becoming more and more difficult to obtain on modern operating systems due to the great progress made in blocking exploits. Physical access can be easier at border crossings or similar moments when a user temporarily loses physical possession of a computer. However, in most other scenarios, the requirement is high, making it unlikely that many users will be affected. In addition, physical possession severely limits the scalability of attacks.
Two other factors that make Boot Hole less scary: Attackers who already have administrative or physical control over a computer have many other options for infecting it with advanced and stealth malware. In addition, several other techniques to bypass Secure Boot are known.
"I would argue that Secure Boot is not the foundation of PC security today, as it is rarely effective and claims to be easy to work with (from Eclypsium) for over a year without long-term correction," HD told me Moore, Vice President for Research and Development at Atredis Partners and expert in software usage. "I am not sure what the buffer overflow in GRUB2 is useful for, as there are other problems if the grub.cfg file is unsigned." "It can be useful as a malware vector, but even then there is no need to exploit a buffer overflow if a custom grub.cfg file can be used instead to chain load the real operating system."
Other researchers seem to agree with the assessment. CVE-2020-10713 has a "medium" severity if the vulnerability is being tracked.
The Eclypsium allegation to which Moore refers included a revocation in February of a boot loader security company that Kaspersky Lab used for a rescue diskette to boot disabled computers. The revocation caused so many problems that Microsoft, who oversees the validation process, undid the change. The revocation not only highlights the difficulty of fixing bugs like boot hole (more on that later), but also the fact that it is already possible to bypass secure boot.
Not scary doesn't mean serious
The hurdles and limitations to exploitation do not mean that the vulnerability should not be taken seriously. Secure Boot was created exactly for the scenario required to take advantage of Boot Hole. The risk is increased by the number of computer and software manufacturers affected. Eclypsium has a more complete list of people affected. You are:
- The Unified Extensible Firmware Interface Forum
- Red Hat (Fedora and RHEL)
- Canonical (Ubuntu)
- SuSE (SLES and openSUSE)
- Different computer manufacturers
- Software providers, including security software
Another serious consideration is the challenge of bringing out updates that do not permanently prevent a machine from starting. This phenomenon is often referred to as "bricking". As the incident with Kaspersky shows, the risk is real and can have serious consequences.
Fixing the mess is a mess in itself
Corrections involve a multi-step process that is not trivial or, in many cases, quick. GRUB2 must first be updated to address the vulnerability and then distributed to vendors or administrators of large organizations. There, engineers must thoroughly test the update for each computer model they support to ensure that the machine does not lock up. Updates must be fixed for computers that do this. Only then can the update be installed in general.
Even then, it is trivial for attackers with the privileges described above to reset GRUB2 to its vulnerable version and exploit the buffer overflow. Although GRUB2 is not normally installed on Windows computers, privileged attackers can usually install it. To fill this gap, computer manufacturers must revoke the cryptographic signatures that validate the old version or the shim firmware that loads the old version.
This step also carries the risk of brick machines. If the signatures are revoked before installing the GRUB2 version – or for Windows computers signatures for other startup components – before extensive tests are carried out, there is a risk that millions of computers will also be blocked.
To prevent this possibility, Microsoft, Red Hat, Canonical and other manufacturers of operating systems and hardware generally offer two-step fixes. First, the GRUB2 update will be released after it has been tested and rated as safe for installation. The signatures will then be revoked after a period of possibly months. The vulnerability is not addressed until the second step is complete.
Microsoft, which operates the certification body that certifies UEFI signatures duly authorized by manufacturers, has made 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 to a system on which Secure Boot is configured to trust the Microsoft UEFI certification authority. We are working on completing the validation and compatibility tests of a required Windows Update package.
A Microsoft spokesman said the company will offer IT administrators who are urgently needed a "mitigation option to install an untested update." At an unspecified time, the spokesman said, Microsoft will release a fix for general availability. Microsoft has released a knowledge base article here.
The recommendations of other affected companies are too numerous to provide in the first version of this article. For now, readers should review websites of affected companies. This post will be updated later to provide links.
There is no need to panic at the moment. The high requirements for exploits make the severity of this vulnerability moderate. And as mentioned earlier, Secure Boot is already vulnerable to other bypass techniques. This does not mean that there is no reason to take this vulnerability seriously. Patch it as soon as possible, but only after thorough testing, either by experienced users or affected operating system and software manufacturers. In the meantime, don't lose sleep.