A high-rated security vulnerability in the Secure Boot function of the majority of laptops, desktops, workstations and servers has been confirmed. Here’s what you need to know about BootHole.

Security researchers at Eclypsium discovered a vulnerability that affects the bootloader used by ‘virtually every’ Linux system, and almost every Windows device using Secure Boot with Microsoft’s standard Unified Extensible Firmware Interface (UEFI) certificate authority.

What is BootHole?

CVE-2020-10713, dubbed BootHole, has a high CVSS rating of 8.2 and sits in the default GRand Unified Bootloader 2 (GRUB2) but affects systems running Secure Boot even if they are not using GRUB2.

If successfully exploited, BootHole opens up Windows and Linux devices to arbitrary code execution during the boot process, even when Secure Boot is enabled. Meaning an attacker could gain persistence for stealthily installed malware and give them, “near-total control” over the device, according to Eclypsium.

The industry response to this threat, discovered in April 2020, has been a joint effort by multiple vendors sharing information to come up with a fix. The result is a global coordinated disclosure today. The likes of Canonical, Microsoft, Red Hat, SUSE, Debian, Citrix, Oracle and VMware are all announcing advisories and mitigations today, with some updates available immediately, others still to come.

A billion devices could be at risk, maybe more

I asked John Loucaides, vice-president of research and development at Eclypsium, how many devices are at risk from the BootHole vulnerability. “The default configuration enables Secure Boot with the Microsoft UEFI Certificate Authority that has signed many vulnerable GRUB versions on nearly every device sold with Windows logo certification since Windows 8,” he says.

Because Secure Boot is the default for most systems sold since Windows 8, Eclypsium noted that this means “the majority of laptops, desktops, servers and workstations are affected, as well as network appliances.” A number that could easily run past a billion.

I also spoke with Joe McManus, director of security at Canonical, which publishes Ubuntu. “This is an interesting vulnerability, and thanks to Eclypsium, Canonical, along with the rest of the Open Source community, has updated GRUB2 to defend against CVE-2020-10713,” he says.

Which is good, but McManus then revealed to me that “during this process, we identified seven more vulnerabilities in GRUB2 which will also be fixed in the updates released today.” It’s a great example of cooperation within the open-source software community, and beyond, that’s for sure.

How worried should you be by this Secure Boot hijack threat to your devices?

The UEFI Secure Boot process, and the part which GRUB2 plays, is highly technical. If you want all the gnarly detail, I strongly recommend you read the Eclypsium “There’s a hole in the boot” report or the Ubuntu knowledge base GRUB2 Secure Boot bypass article.

The abridged version is that UEFI Secure Boot uses cryptographic signatures to validate code integrity as needed during the boot process and, as already mentioned, is the default standard for most laptops, desktops and servers. Every bit of firmware and software is checked before being run, and any not recognized are not executed.

As you can imagine, determining who is allowed to sign the code trusted by the Secure Boot database is pretty important, and Microsoft’s third-party UEFI certificate authority (CA) is the industry standard.

Open source projects and others use a shim, a small application, to contain the vendor certificate and code to verify and run the GRUB2 bootloader. That shim is verified using the Microsoft third-party UEFI CA before the shim loads and verifies the GRUB2 bootloader.

BootHole is a buffer overflow vulnerability involving how GRUB2 parses the config file and enables an attacker to execute arbitrary code and gain control over the booting of the operating system.

The real-world threat from BootHole

If you can feel a ‘but’ coming on, that’s because there is one: but only if the attacker is already on the system and has elevated privileges. This is not a remote code execution vulnerability; if it were, then I imagine, rather than being a high-rated vulnerability, it would be a critical one.

“The bootkit attacks that Secure Boot aims to protect against are usually employed for persistence, disruption, or to bypass other security measures,” Loucaides says, adding that “recent ransomware campaigns have attacked bootloaders on newer UEFI systems.” Because Secure Boot would continue operating normally, Loucaides told me, “hypothetically, this would also be a good way to hide an attack for a long time, stealing credentials or waiting to flip a kill switch.”

However, a threat intelligence expert and Cyjax CISO, Ian Thornton-Trump, is not overly concerned. “I’m reluctant to press the complete panic button on this issue,” he says, “weaponizing it has to be dependent on a chain of exploits, failure of layered security, to launch an attack in order to gain access to the OS boot loader.”

So, while it is indeed a hugely widespread vulnerability, impacting almost all platforms, in theory, Thornton-Trump says the “threat landscape is exploiting far more readily available attack surfaces, such as process hijacks and DLL injection.” Joe McManus also says that he does “not see it being a popular vulnerability used in the wild.”

I reached out to Microsoft, and a spokesperson told me that it was “aware of a vulnerability in the Grand Unified Boot Loader (GRUB), commonly used by Linux,” and that Microsoft is “working to complete validation and compatibility testing of a required Windows Update package.”

I understand that when the relevant Windows Update becomes available, customers will be notified by way of a revision to the security advisory published as part of today’s coordinated disclosure and will include a mitigation option to install as an un-tested update.

The Linux vendor response to BootHole

Peter Allor, product security director at Red Hat, said, “we are working closely with the Linux community as well as our industry partners to deliver updates to affected Red Hat products, including Red Hat Enterprise Linux.”

A Debian spokesperson told me that “Debian is working with the rest of the Linux community to prepare updates to address this vulnerability. Security is very important to us, our users, and our community.”

A SUSE spokesperson says “we’re aware of the Linux vulnerability called BootHole shared by Eclypsium today, and our customers and partners can rest assured we have released fixed GRUB2 packages which close the BootHole vulnerability for all SUSE Linux products today and are releasing corresponding updates to Linux kernel packages, cloud image and installation media.”

So, to summarize then, patches for GRUB2 will be made available to address the vulnerability with Linux distributions and other vendors updating their installers, bootloaders, and shims. New shims will need to be signed by the Microsoft 3rd Party UEFI CA, and 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. The UEFI revocation list in the firmware of each affected system will eventually need to be updated to prevent BootHole from being exploitable during boot.

0 Shares:
Leave a Reply

Your email address will not be published. Required fields are marked *

You May Also Like
Read More

DevOps: A cheat sheet

This comprehensive guide covers DevOps, an increasingly popular organizational structure for delivering rapid software deployments in the enterprise.…