New flaw neuters Secure Boot, but there’s no reason to panic. Here’s why

GRUB2, one of the world’s most-widely used programs for booting up 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 mainly used in computers running Linux, attacks that exploit the vulnerability can be performed on many PCs running Windows as well.

The vulnerability, discovered by researchers from security firm Eclypsium, poses yet another serious threat to UEFI Secure Boot, an industry-wide standard that uses cryptographic signatures to ensure that software used during startup is trusted by a computer’s manufacturer. Secure Boot was designed to prevent attackers from hijacking the boot process by replacing the intended software with malicious software.

Stealthier, more powerful, and hard 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 the malware to be stealthier than most malware, survive operating system reinstallations, and circumvent security protections built into the OS.

Boot Hole, as the researchers have named the vulnerability, stems from a buffer overflow in the way that GRUB2 parses text in grub.cfg, the boot loader’s main configuration file. By adding long text strings in the file, attackers can overfill the memory space allotted for the file and cause malicious code to spill into other parts of memory, where it then is executed.

The configuration file isn’t digitally signed, so Secure Boot won’t detect when it has been maliciously altered. GRUB2 also doesn’t use address space layout randomization, data execution prevention, and other anti-exploit protections that are standard in operating systems. These omissions make it trivial for attackers who already have a foothold on the targeted computer to exploit the flaw. From there, they can fully bypass a protection many people expect to prevent bootkits from taking hold.

Besides the Eclypsium report, Debian provides a solid overview here.

But there are some major catches

The severity of the vulnerability, however, is offset by a few things. First, the attacker must have either administrative rights over the computer or physical access to the machine. Administrator-level control is increasingly hard to gain on modern OSes because of major advances they’ve made to block exploits. Physical access may be easier during border crossings or similar moments when a user briefly loses physical possession of a computer. But the requirement is steep in most other scenarios, making it unlikely many users are affected. What’s more, 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 of a computer already have plenty of other ways to infect it with advanced and stealthy malware. Furthermore, there are several other known techniques for bypassing Secure Boot.

“I’d argue that Secure Boot is not the foundation of PC security today, because it is rarely effective, and by their [Eclypsium’s] own claim, it has been easy to bypass for over a year now, with no long-term fix 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 the buffer overflow in GRUB2 is useful for, since there are other problems if the grub.cfg is unsigned. “It may be useful as a malware vector, but even then, there is no reason to exploit a buffer overflow when a custom grub.cfg file can be used instead to chain load the real OS.”

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 Moore referred to involves a revocation in February of a bootloader security firm Kaspersky Lab used for in a rescue disk for starting up disabled computers. The revocation caused so many problems that Microsoft, which oversees the validation process, rolled back the change. The revocation underscores not only the difficulty of patching flaws like Boot Hole (more about that later) but also the fact that it’s already possible to circumvent Secure Boot.

Not scary doesn’t mean not serious

The hurdles and limitations of exploitation don’t mean that the vulnerability isn’t worth taking seriously. Secure Boot was created precisely for the scenario required to exploit Boot Hole. The risk is compounded by the number of affected computer and software makers. 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 in pushing out updates that won’t permanently prevent a machine from starting up, a phenomenon often referred to as “bricking.” As the Kaspersky incident shows, the risk is real and can have dire consequences.

Fixing the mess is a mess in itself

Fixes involve a multistep process that won’t be trivial or, in many cases, fast. First, GRUB2 must be updated to fix the vulnerability and then distributed to manufacturers or administrators of large organizations. There, engineers will have to thoroughly test the update on each computer model they support to make sure the machine doesn’t brick. Updates will have to be fixed for machines that do. Only then will the update be ready to install generally.

Even then, it will be trivial for attackers with the above-described privileges to roll back GRUB2 to its vulnerable version and exploit the buffer overflow. Although Windows machines typically don’t have GRUB2 installed, privileged attackers can usually install it. To close this loophole, computer manufacturers will have to revoke the cryptographic signatures that validate the old version or the “shim” firmware that loads the old version.

This step also comes at the risk of bricking machines. If the signatures are revoked before the GRUB2 version is installed—or in the case of Windows machines, signatures for other boot components—before ample testing, millions of computers are at risk of being bricked as well.

To prevent this possibility, Microsoft, Red Hat, Canonical, and other OS and hardware makers are generally offering fixes in two steps. First, the GRUB2 update will be released and only after it’s tested and deemed safe to be installed. Then, after a period that may last months, the signatures will be revoked. Only after the second step is completed will the vulnerability be patched.

Microsoft, which operates the certificate authority that certifies UEFI signatures 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 spokesman said the company will provide IT admins who have an urgent need with a “mitigation option to install an un-tested update.” At an unspecified time, the spokesman said, Microsoft will release a fix for general availability. Microsoft has issued a knowledge base article here.

Advisories from other affected companies are too numerous to provide in the initial version of this article. For the time being, readers should check websites of affected companies. This post will be updated later to provide links.

For now, there’s no reason to panic. The steep requirements for exploits make the severity of this vulnerability moderate. And as already mentioned, Secure Boot is already vulnerable to other bypass techniques. That doesn’t mean there’s no reason to take this vulnerability seriously. Patch it as quickly as possible, but only after thorough testing, either by experienced users or affected OS and software makers. In the meantime, don’t lose any sleep.