icetray - Fotolia
'BootHole' bug puts most Linux, Windows systems in jeopardy
Hardware security vendor Eclypsium discovered a bootloader vulnerability that bypasses Secure Boot protection and affects a majority of modern Linux and Windows systems.
A vulnerability in a widely-used bootloader could jeopardize a majority of modern Windows and Linux systems, even when Secure Boot is enabled, according to new research by Eclypsium.
The hardware security vendor on Wednesday published a research paper detailing the new vulnerability, dubbed "BootHole," in GRUB2, a popular bootloader for Linux systems. While the bug was found in GRUB, it does not mean that only Linux systems using GRUB are affected; Eclypsium said the vulnerability extends to Windows systems using Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.
"As a result, we believe that the majority of modern systems in use today, including servers and workstations, laptops and desktops, and a large number of Linux-based OT and IoT systems, are potentially affected by these vulnerabilities," Eclypsium wrote in the research paper.
The "BootHole" vulnerability, which received a 8.6 CVSS score, bypasses Secure Boot, an industry standard developed by various vendors to protect devices during the boot process. Secure Boot was designed to ensure that a device is using authorized bootloaders and firmware by authenticating the software with valid digital signatures. However, Eclypsium discovered a problem with how GRUB2 parses its configuration file, which allows unauthorized parties to bypass the signature check.
"Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device," Eclypsium wrote in the paper.
According to the research paper, almost all signed versions of GRUB2 are vulnerable to BootHole, which impacts not just operating systems but hypervisors such as Xen, too.
Eclypsium researchers first discovered the bug in early April and started reporting the issue to impacted vendors, said Jesse Michael, principal researcher at Eclypsium. Researchers began looking at bootloaders in February after a previous issue with Secure Boot, found last year, raised unexpected problems even after the update was pushed through, he said.
"We started looking at other bootable tool vendors, in addition to mainstream Linux distributions. There are a bunch of other people who use Grub as well, so we started taking a look at some of those and found an issue with basic fuzzing," Michael said. "We figured out this is also in Ubuntu and it's also in upstream Linux and we were able to prove we could get arbitrary code execution during the boot process, even when Secure Boot was turned on and enforcing this signature verification."
Coordinated disclosure and mitigation
The research team immediately notified maintainers, Linux distributions, Microsoft and the UEFI security response team. Microsoft helped in the coordination as well because they sign all the bootloaders, Michael said, and they contacted several affected parties that Eclypsium missed.
Michael said the disclosure process, which typically allows 90 days before public disclosure, was complicated because of the large number of organizations involved, which included Oracle, Red Hat, Citrix, VMware and others.
"Every system that runs Windows or Linux is affected by this. That's a big problem. That's a ton of systems," Michael said.
The broad range of affected operating systems and devices, along with an extensive coordination effort, made "BootHole" one of the most challenging vulnerabilities Eclypsium has discovered. For example, one coordination group has around 70 different people and almost 20 different organizations.
"Our team has been doing this for years and we've had a lot of large coordination and generally speaking it can be an easy technical problem," John Loucaides, vice president of research and development at Eclypsium, said. "However, this fix is not normal. It's going to be harder. You're going to have think about it because you're going to have to test it on your systems before you actually go doing things like installing revocation. If you don't do that the system will remain vulnerable. It is not going to work just like any other update."
While Eclypsium and Microsoft notified all the people they know are affected, outliers will likely remain.
"There's also regulated environments that get approval for it before you apply updates," Michael said. "For example, many ATMs today are just Windows systems running special code and hardware. In those cases, they might have an instance where it's a modern enough system that it's running UEIFI Secure Boot and they'd also need to push updates out to have those systems protected. There's edge cases where it becomes more difficult."
While the core vulnerability itself is a simple bug, there are additional issues researchers found that are more difficult to fix, says Michael.
"The fix for the buffer overflow we found is a one-line code change, but the big, big problem is all of the process and coordination around that. Technically, it's an easy fix but coordinating and deploying the fix is not," Michael said. "Especially if you're an enterprise deploying it to hundreds or thousands of machines. You have to test it on the specific firmware of the specific device to know it's going to be okay. "
Eclypsium said mitigation will require not just patches for GRUB2 but updates to additional bootloaders, installers and other types of software. Applying the fixes will be challenging, Michael said, because if they are not applied in the right order, vulnerable systems may not boot properly.
Unlike the fix, exploiting the flaw is relatively simple.
"In some sense it's easier to exploit this flaw," Michael said. "In the operating system and application world, there's been a lot of mitigation put in place specifically to make exploitation harder. Now you have things like address randomization, sandboxes you have to break out of and all kinds of things like that. In the execution environment that Grub is running in, basically the UEFI boot process doesn't have a lot of these mitigations so it's a lot easier to write an exploit for this. It's pretty quick and easy to turn it into a full exploit."
While BootHole proved problematic, Loucaides said working on the vulnerability brought the industry together and moved it in a positive direction.
"Firmware hasn't had the attention that operating systems and applications have had, so this sort of an activity is making things better," he said. "But it's one of those 'no pain, no gain' things. We are figuring out how to do it more effectively."
