There is a newly discovered vulnerability in a widely deployed boot loader that is included in most Linux distributions that could give an attacker access to the earliest portions of a computer’s start-up process and eventually complete control of the system. The flaw in the GRUB 2 boot loader can also affect other systems that uses UEFI Secure Boot, including Windows computers, under some specific conditions.
The vulnerability (CVE-2020-10713) potentially affects hundreds of millions of devices, including embedded systems, network devices, IoT devices, as well as servers, desktops, and laptops. The flaw is a buffer overflow in the GRUB 2 bootloader, and though an exploit against it could grant complete control over the target system, the attacker would need privileged access to the machine in order to exploit the vulnerability. Researchers at Eclypsium discovered the bug in April and have been collaborating with dozens of affected vendors and project teams, including Microsoft and various Linux distributions. Although fixes will be rolling out beginning today, it could be several months before most affected devices are patched, thanks to the complexity of the Secure Boot process and the difficulty of getting the fix to some of the devices.
“This attack would be done as part of an exploit chain to gain persistence. This would not be your first toehold on a machine, You would need privileges to mount the bootloader and partition and generally need root privileges on a Linux system. In Windows generally you’d need admin privileges,” said Jesse Michael, principal researcher at Eclypsium.
A boot loader is typically the first piece of software that runs when a device begins to boot, and it then hands over control to the operating system, which handles the rest of the boot process. If an attacker can gain access to the boot loader, he can then control the subsequent portions of the boot process and make modifications to the OS. That kind of attack is complex and rare, but there have been a number of bootkits uncovered over the years that are capable of modifying the master boot record (MBR). To help defend against those attacks, an industry coalition developed a standard called Secure Boot that ensures that only signed and trusted software and firmware components load during the boot process.
The basis of that standard is a third-party certificate authority maintained by Microsoft, which provides the signing service for Secure Boot. During the manufacturing process, vendors that implement Secure Boot install two databases on their devices: a signature database and a revoked signature database. These are essentially allow and deny lists that determine what firmware, loaders, and drivers can be loaded.
“In short, third parties can submit their code to Microsoft, and Microsoft will validate and sign the code with the Microsoft CA. This establishes a chain of trust that only requires OEMs to enroll the Microsoft 3rd Party UEFI CA to their platforms to enable them to boot third-party installation media and operating systems by default when Secure Boot is enabled,” the Eclypsium report says.
"It will take a while to get this fixed in the ecosystem."
“Due to legal issues arising from license incompatibilities, open-source projects and other third parties build a small application called a “shim,” which contains the vendor’s certificate and code that verifies and runs the bootloader (GRUB2). The vendor’s shim is verified using the Microsoft 3rd Party UEFI CA and then the shim loads and verifies the GRUB2 bootloader using the vendor certificate embedded inside itself.”
The GRUB2 bootloader was developed by the GNU Project and it is included in the majority of Linux distributions. When it runs, the boot loader reads information from a configuration file and the vulnerability is a buffer overflow that occurs as GRUB 2 is parsing content from that file. Because the configuration file isn’t signed, an attacker could exploit the flaw to modify the file and add malicious code.
This is certainly not a trivial process and the attacker would not only need root privileges on the target device, but knowledge of how the boot loader works. Changes to boot loaders can have a cascading effect and cause serious problems, including bricking devices. And an attacker who has root access to a device can likely find simpler ways to gain persistence. But, a successful exploit against this vulnerability would be quite serious. Not only would the attacker have persistence, but he would have the ability to control which software loads first and then everything that loads after that.
“What scares me is the ability to inject code that would run before you boot into single user mode on a Linux system and maintain persistence,” said Tony Lambert, an intelligence analyst at Red Canary.
Exploiting this flaw on a Windows machine would be even more complicated. In that scenario, the attacker would need the ability to replace the Windows boot loader with the vulnerable GRUB 2 boot loader, then exploit the vulnerability to get code execution before Windows runs.
Because of the complexity of the boot loader itself and the myriad dependencies involved, the process for fixing this vulnerability is a difficult one. The affected Linux distributions are releasing updates today and Microsoft is working with the UEFI Forum to release an updated revocation list for Secure Boot. But the update won’t be automated because of the possibility of something going wrong and the need for troubleshooting if that happens.
“It’s likely we haven’t found all of the people affected by this. It will take a while to get this fixed in the ecosystem,” MIchael said.