By Jack M. Germain
Jul 29, 2020 10:10 AM PT
If you are a Windows or Linux user, brace yourself for a long siege of vulnerability nightmares. The fix will be long and treacherous and could brick your computers.
Eclypsium researchers Wednesday released details of a set of newly discovered vulnerabilities dubbed “BootHole” that opens up billions of Windows and Linux devices to attacks.
This is a serious vulnerability with a Common Vulnerability Scoring System (CVSS) rating of 8.2. The highest assigned rating on this severity scale is 10.
The BootHole vulnerability in the GRUB2 bootloader opens up Windows and Linux devices using Secure Boot to attack. To mitigate the attack surface, all operating systems using GRUB2 with Secure Boot must release new installers and bootloaders, the researchers warned.
Attackers exploiting this vulnerability could gain near-total control of the compromised device. The majority of laptops, desktops, servers, and workstations are affected, as well as network appliances and other special-purpose equipment used in industrial, healthcare, financial, and other industries, according to the report.
Researchers warned that mitigating this vulnerability will require the specific vulnerable program to be signed and deployed. They also advised that vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack.
Plugging this vulnerability hole will likely be a long process. It will take considerable time for IT departments within organizations to complete patching, the researchers said.
Eclypsium has coordinated the responsible disclosure of this vulnerability with a wide variety of industry entities, including OS vendors, computer manufacturers, and the Computer Emergency Response Team (CERT). A number of these organizations are listed in the report and were part of Wednesday’s coordinated disclosure.
“This is probably the most widespread and severe vulnerability that we have found at Eclypsium. Many of the issues we found in the past were specific to a given vendor or model, whereas this issue is pervasive. This vulnerability in Secure Boot affects the default configuration of most systems deployed in the past decade, Jesse Michael, principal researcher for Eclypsium, told TechNewsWorld.
This vulnerability was assigned CVE-2020-10713 GRUB2.
Finding and Patching Holes in the Boot
The Eclypsium researchers stumbled on the trail of BootHole vulnerabilities somewhat by accident while doing some routinely proactive exploring, according to Michael.
“We were exploring any weak links in the whole secure boot infrastructure. Since we had previously seen a similar issue
with Secure Boot and the Kaspersky boot loader, we thought we should take a deeper look at that area. We did some fuzzing on GRUB2, which is widely used by most Linux distributions, and found a vulnerability that turned out to be much larger than we expected,” he said.
Fuzzing, or fuzz testing, is an automated software testing technique to find hackable software bugs. Testers randomly provide different permutations of data into a target program until one of those permutations reveals a vulnerability.
Researchers have yet to see bad guys exploiting this specific vulnerability in the wild, he noted. But threat actors have been using malicious Unified Extensible Firmware Interface (UEFI) bootloaders.
“This sort of attack has been used by malware, including wipers and ransomware, for a long time, and Secure Boot was designed to protect against this technique. The BootHole vulnerability makes most devices susceptible even when Secure Boot is enabled. Previous threat actors used malware tampering with legacy OS bootloaders including APT41 Rockboot, LockBit, FIN1 Nemesis, MBR-ONI, Petya/NotPetya, and Rovnix,” Michael noted.
What BootHole Does
Attackers can leverage the GRUB2 bootloader that most Linux systems and Windows computers use to gain arbitrary code execution during the boot process. This can happen even when Secure Boot is enabled. Attackers exploiting this vulnerability can install persistent and stealthy bootkits or malicious bootloaders that could give them near-total control over the victim device, according to Eclypsium’s report.
What makes this BootHole vulnerability even more threatening is its ability to affect systems using Secure Boot, even if they are not using GRUB2. Almost all signed versions of GRUB2 are vulnerable. This means that nearly every Linux distribution is affected. In addition, GRUB2 supports other operating systems, kernels, and hypervisors such as Xen.
This problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third-Party UEFI Certificate Authority. Thus, BootHole affects the majority of laptops, desktops, servers, and workstations. The vulnerability also threatens network appliances and other special purpose equipment used in industrial, healthcare, financial, and other industries. This vulnerability makes these devices susceptible to attackers such as the threat actors recently discovered using malicious UEFI bootloaders, noted researchers at Eclypsium.
If the Secure Boot process is compromised, attackers can control how the operating system is loaded and subvert all higher-layer security controls. Recent research identified ransomware in the wild using malicious EFI bootloaders as a way to take control of machines at the time of boot. Previously threat actors used malware tampering with legacy OS bootloaders including APT41 Rockboot, LockBit, FIN1 Nemesis, MBR-ONI, Petya/NotPetya, and Rovnix, noted the report.
Circular Firing Squad
Attackers can also use a vulnerable bootloader against the system, the report writers added. For example, if BootHole finds a valid bootloader with a vulnerability, it can replace a piece of malware in the device’s existing bootloader with the vulnerable version.
The bootloader would be allowed by Secure Boot and give the malware complete control over the system and the operating system itself. Mitigating this requires very active management of the dbx database used to identify malicious or vulnerable code.
The Secure Boot process has potential problems with many pieces of code. A vulnerability in any one of them presents a single point of failure that could allow an attacker to bypass Secure Boot, according to Eclypsium’s BootHole report.
Additionally, trying to fix the vulnerabilities that BootHole seeks can be potentially deadly to the hardware and software. Updates and fixes to the Secure Boot process can be particularly complex. The complexity poses the additional risk of inadvertently breaking machines.
The boot process by nature involves a variety of players and components including device OEMs, operating system vendors, and administrators. The boot process’s fundamental nature makes any sort of problems along the way poses a high risk of rendering a device unusable. As a result, updates to Secure Boot are typically slow and require extensive industry testing.
Buffer Contributor
The BootHole vulnerability is a buffer overflow that occurs in GRUB2 when parsing the grub configuration file, according to Eclypsium’s researchers. The GRUB2 configuration file (grub.cfg) is merely a text file. It is typically not signed like other files and executable code.
This vulnerability enables arbitrary code execution within GRUB2 and ultimately control over the booting of the operating system. As a result, an attacker could modify the contents of the GRUB2 configuration file to ensure that attack code is run before the operating system is loaded. In this way, attackers gain persistence on the device, according to the report.
To pull off such an intrusion, the attacker would need elevated privileges. But it would provide the attacker with a powerful additional escalation of privilege and persistence on the device. This would occur with or without Secure Boot enabled and properly performing signature verification on all loaded executables.
Challenging Mitigation Effort
Eclypsium warned that plugging BootHole will require the release of new installers and bootloaders for all versions of Linux and potentially Windows. Vendors will have to release new versions of their bootloader shims signed by the Microsoft Third-Party UEFI CA.
Until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system. This means that every device that trusts the Microsoft Third-Party UEFI CA will be vulnerable for that period of time.
The Unified Extensible Firmware Interface (UEFI) Forum originally developed Secure Boot as a way to protect the boot process from these types of attacks.
This configuration file is an external file commonly located in the EFI System Partition and can therefore be modified by an attacker with administrator privileges without altering the integrity of the signed vendor shim and GRUB2 bootloader executables.
The buffer overflow allows the attacker to gain arbitrary code execution within the UEFI execution environment, which could be used to run malware, alter the boot process, directly patch the OS kernel, or execute any number of other malicious actions.
This vulnerability is not architecture specific. It is in a common code path and was also confirmed using a signed ARM64 version of GRUB2.
Canonical’s security team found additional vulnerabilities related to the GRUB2 code in response to the Eclypsium report, the Eclypsium report noted. That will further impact on the mitigation path.
“Those vulnerabilities discovered by the Canonical security team were all of medium severity. There were also dozens of further vulnerabilities identified by other organizations that do not yet have individual CVEs assigned, said Michael.
What’s Needed to Fix
Full mitigation will require coordinated efforts from affected open-source projects, Microsoft, and the owners of affected systems, among others. The list of tasks to fix BootHole, according to the report, will include:
- Updates to GRUB2 to address the vulnerability.
- Linux distributions and other vendors using GRUB2 will need to update their installers, bootloaders, and shims.
- New shims will need to be signed by the Microsoft 3rd Party UEFI CA.
- Administrators of affected devices will need to update installed versions of operating systems in the field as well as installer images, including disaster recovery media.
- Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.
More Bugaboos Possible
Full deployment of this revocation process to enterprises will likely be very slow, researchers suggested. UEFI-related updates have a history of making devices unusable. So, vendors will need to be very cautious to prevent the fix from turning computers into bricks.
For example, if the revocation list (dbx) is updated, the system will not load. So vendors will have to apply revocation list updates over time to prevent breaking systems that have yet to be updated.
Also, cases exist where updating the dbx can be difficult. The edge conditions involve computers with dual-boot or deprovisioned setups.
Other circumstances can further complicate matters. For instance, enterprise disaster recovery processes can run into issues where approved recovery media no longer boots on a system if dbx updates have been applied.
Another situation is when a device swap is needed due to failing hardware. New systems of the same model may have already had dbx updates applied and will fail when attempting to boot previously-installed operating systems. So before dbx updates are pushed out to enterprise fleet systems, recovery and installation media must be updated and verified as well.
Few Workarounds
With the report’s dire warnings about boot fixes bricking hardware, few potential workarounds exist to prevent the cure being worse than the attack results. Michael expects attacks will occur that take advantage of this, if they haven’t already.
“If left without action or mitigation, this will leave a gaping hole on all affected systems,” he said. “There could be unexpected consequences to the cure as well.”
Revocation updates are not common, and this is going to be the largest revocation ever done. Bugs in this rarely used part of firmware, could cause systems to behave unexpectedly after the update. In order to avoid such issues, the revocation will not happen automatically.
“This forces security teams to carefully manage this issue using manual intervention,” cautioned Michael.
Workarounds may need to be tweaked by various vendors to be effective for their products. Bootloader vulnerabilities have been found in the past that vendors successfully patched, according to Charles King, principal analyst at Pund-IT.
For example, one was revealed in March that affected LG phones, and in June the company announced
that it had issued a patch for phones going back seven years.
What’s Worse: Meltdown and Spectre or BootHole?
The Meltdown and Spectre vulnerabilities of 2019 impacted confidentiality. They allow an attacker to steal secrets.
This vulnerability impacts integrity and availability, as well as confidentiality. Therefore, BootHole has the potential for much broader damage, according to Michael.
Using the industry-standard CVSS severity score, Meltdown and Spectre were classified as Medium severity vulnerabilities, and BootHole is rated as a High severity vulnerability, he said.
While the BootHole vulnerability occurs in software (system firmware), Meltdown and Spectre exploited hardware flaws that were baked into many CPUs. A major challenge with Meltdown and Spectre has been that fixes often significantly impact CPU performance, noted King.
“It seems unlikely that BootHole fixes will similarly impact system or device performance,” he told TechNewsWorld.
As to which vulnerability is more dangerous is relative. Just because a vulnerability exists does not mean that people will find a way to effectively exploit it. Though Meltdown and Spectre attracted a great deal of attention when they were revealed several years ago, he has not seen any reports of successful exploits, King said.
What to Do
Most users will want to deploy the updates that vendors are coming out with beginning on July 29, Michael suggested. In addition to the automatic updates released by OS vendors, manual action will be needed to revoke the old, vulnerable versions of grub.
“Until this is done, systems will remain vulnerable,” he warned.
Enterprise security teams should also consider threat hunting or monitoring activities that look at the bootloaders present on operational systems, suggested Michael. This should reveal which systems have suspicious-looking bootloaders and grub configuration files.
“Considering the complexity of deploying these updates to an enterprise, such monitoring may be an important workaround to buy time while updates are tested and deployed,” Michael concluded.
The Eclypsium report is available here.
Jack M. Germain has been an ECT News Network reporter since 2003. His main areas of focus are enterprise IT, Linux and open-source technologies. He is an esteemed reviewer of Linux distros and other open-source software. In addition, Jack extensively covers business technology and privacy issues, as well as developments in e-commerce and consumer electronics. Email Jack.
