Linux GRUB2 bootloader flaw breaks Secure Boot on most computers and servers

Operating system maintainers, computer manufacturers, security and virtualization software vendors have worked together over the past few months to coordinate a unified response to a vulnerability that allows attackers to bypass boot process integrity verification, one of the key security features of modern computers. The flaw is located in the GRUB2 Linux bootloader, but because of how Secure Boot is implemented, it can be used to compromise the booting process of Windows and other systems as well.

Getting the patches that were announced today installed on all impacted computers and devices will require manual testing and deployment and will likely take a long time. It’s reasonable to expect that some systems will never be updated and will remain vulnerable to boot-level malware and rogue firmware modifications.

What is Secure Boot and how does it work?

Secure Boot is a standardized mechanism for cryptographically verifying the integrity of all components involved in the process of booting up a computer until the operating system is initialized and takes over execution. Secure Boot is a feature of the Unified Extensible Firmware Interface (UEFI), which has replaced the legacy BIOS firmware in all modern computers.

Almost all UEFI implementations ship with a root key that belongs to Microsoft and establishes the root of trust for the entire platform. This is known as the Microsoft 3rd Party UEFI Certificate Authority (CA). Once Secure Boot is turned on a computer, every boot component needs to be signed with a key that is tied back to this CA for the operating system to start, which means that Linux distributions need to have their bootloaders signed by Microsoft, too.

GRUB2, short for the Grand Unified Bootloader version 2, is the standard bootloader used by most Linux systems. This is a relatively complex piece of software that supports many features and configurations, so every Linux distribution maintains its own GRUB2-based bootloader.

To avoid having Microsoft re-sign their GRUB binaries every time a modification or an update is made to them, Linux vendors ask Microsoft to sign a much simpler piece of code called a “shim” bootloader, which is then used to verify and initialize GRUB. The shims usually contain a certificate controlled by the Linux distribution, giving its maintainers the freedom to then sign their GRUB binaries and other OS components with their own certificates that are now part of the chain of trust.

Computers ship with UEFI, which has a Microsoft platform certificate inside. This certificate is used to validate other components that are part of the boot chain, including shim bootloaders signed by Microsoft for other operating systems like Linux. The shim bootloaders then verify the full-blown GRUB-based bootloaders that are signed by the Linux distribution maintainers themselves.

One vulnerability triggers a full-blown GRUB audit

Researchers from security firm Eclypsium found a buffer overflow vulnerability in the way GRUB2 parses content from its configuration file called grub.cfg. While the GRUB binary is usually signed, its configuration file is not because it’s meant to be editable by system administrators who might want to change different options for how the OS is initialized or add boot entries when they set up computers with multiple operating systems choices.

By adding specifically crafted content in the configuration file, attackers can exploit the vulnerability to execute malicious code in the context of the trusted bootloader before the operating system starts. This gives them a highly privileged position and persistence on the system, as well as total control over the OS and its kernel. Boot-level attacks, known as boot rootkits or simply bootkits, used to be quite common a decade ago and were one of the primary reasons why Secure Boot was created.

Such attacks still exist and can target systems that don’t have Secure Boot enabled. For example, the Petya and NotPetya ransomware programs were known for encrypting or the Master Boot Record (MBR) of computers. A cybercriminal gang known as FIN1 used a utility to modify the system Volume Boot Record (VBR) and start their Nemesis backdoor before Windows or security software had a chance to fully initialize.

Secure Boot is not a perfect solution and vulnerabilities in certain UEFI implementations in the past have allowed attackers to bypass the verification, but those attacks were generally limited to specific computer manufacturers or UEFI variants. The GRUB2 vulnerability found by Eclypsium, however, can have a much more widespread impact because of GRUB’s versatility: It can be used to initialize different operating systems, including Windows, for example, in dual-boot or multi-boot configurations.

This means that if attackers want to install a bootkit on a Windows computer with Secure Boot enabled, they can replace the Windows bootloader with a signed shim from a Linux distribution and a version of GRUB2 that has this vulnerability. Then they can configure GRUB2 to initialize Windows and exploit the vulnerability to gain persistence and control of the OS. This will not break the trust chain, because the Linux shim bootloader and GRUB2 will have signatures that are valid and linked to the Microsoft Secure Boot key inside UEFI.

Replacing the Windows bootloader with GRUB2 does require the attacker to have administrator privileges on the system, and so does modifying the GRUB2 configuration file on Linux, but Secure Boot was designed to protect the integrity of the boot process even in such cases.

“One of the explicit design goals of UEFI Secure Boot is to protect against this type of attack in the first place, even when someone has gained administrator privileges on the system,” Jesse Michael, principal researcher at Eclypsium, tells CSO. “The administrator is not supposed to be able to turn off Secure Boot without some kind of physical presence attestation. By going into UEFI BIOS and choosing BIOS options you can turn off Secure Boot, but you’re not supposed to be able to do it from runtime within the operating system.”

The vulnerability found by Eclypsium is tracked as CVE-2020-10713 and is rated 8.2 (high) in the Common Vulnerability Scoring System (CVSS), but it’s not the only one. After the company privately reported the vulnerability, a security audit of the GRUB2 code base was performed by security teams from Oracle, Red Hat, Canonical and VMware, resulting in dozens of other vulnerabilities and dangerous code operations being found and fixed. Some of them also have CVE identifiers — CVE-2020-14308, CVE-2020-14311, CVE-2020-14309 and CVE-2020-14310 — but others do not.

Problems with Secure Boot trust revocation

This code review was necessary because revoking trust in the vulnerable versions of GRUB2 is a complicated process that requires a big industry collaborative effort, so doing it every few months when a new flaw is found is not practical. Linux distributions will update their bootloaders to use a patched version of GRUB2, but what would stop attackers with admin access to a system from replacing the patched version with an older and vulnerable one that’s signed with the certificate contained in the shim bootloader? In other words, what is required to prevent a downgrade attack in this case?

There is a mechanism in place, but it’s not very straightforward. The UEFI Secure Boot mechanism has a revocation list called dbx that can contain a list of blacklisted bootloader binaries, even if they’re signed with a valid certificate. This list is stored in the same flash memory chip where the UEFI firmware is stored, but it can be updated from inside the operating system with a special utility that also uses cryptographic verification and validation to ensure the update requests are legitimate.

All existing Linux shim bootloaders or GRUB binaries that have been signed directly — not through a shim — need to be added to this revocation list on every affected computer or device. The Eclypsium researchers tell CSO that the revocation list will have around 200 different entries. Linux distributions whose shims will be blacklisted will have to get new shims signed by Microsoft and update their installers, shims as well as GRUB2 bootloaders.

Canonical, which maintains Ubuntu, and Debian are two exceptions because they used intermediary certificates to sign their bootloaders, which are tied back to their own UEFI-trusted CA certificates. They only have to revoke and blacklist their intermediary certificate, generate a new one and sign the new bootloaders with it.

“One of the issues that came up is that the scope of this is so broad and there’s been a lot of different parties involved,” Michael says. “I think there are around 70 people in one of the coordination groups that has all the distros and affected vendors that we’ve identified so far. Because this has been so painful, there’s been an effort to try and make some process improvements and fix some technical issues. They’re trying to push things so that vendors set things up more like Canonical and Debian had, where they only need to revoke a single cert instead of multiple shims or multiple GRUB instances. So, the idea is that the next time this happens, we want it to be less painful.”

Another problem is that this UEFI Secure Boot revocation mechanism has not been extensively used in the past and might have implementation differences from system to system or vendor to vendor. In February, Microsoft released a Windows update that updated the UEFI dbx to blacklist a vulnerable UEFI loader included with Kaspersky Rescue Disk that could be used to bypass Secure Boot. The update triggered boot failures on some computers and Microsoft was forced to halt it.

In this new case, the revocation update that will be signed by Microsoft, will be optional and will need to be installed manually, at least in the beginning, so that administrators can test them on all sorts of devices.

“If you’re an IT administrator for an enterprise environment, you want to test this on every single model that you have deployed in your environment before pushing it out,” Michael tells CSO. “Make sure there are no compatibility issues. Rescue discs or data and disaster recovery media or golden images like installation images that have the enterprise’s specific applications would need to be updated too and be ready to go before you’re pushing these out, because if you push these out to somebody in the field, a system goes down and the rescue media doesn’t boot, you’re gonna have a bad day. Or maybe there’s a network boot scenario that people have in the data center where secure boot is on but they’re doing network boot, so boot media needs to be updated as well.”