Despite a drop in overall sales of computers, a staggering 286.2 million Windows-based PCs were sold in 2022. Each of these computers was released with firmware based on the Unified Extensible Firmware Interface (UEFI), an alternative to the legacy Basic Input/Output System (BIOS), which provides an extensible intersection between hardware and the OS itself. The UEFI standard also identifies reliable ways to update this firmware from the OS. Despite its ubiquitous and indispensable role, this piece of software remains invisible to most users. However, attackers have not forgotten about it.

The attack dubbed BlackLotus first exposed a bootkit (advanced form of malicious software) that cannot be easily detected or removed. Many vendors, including Microsoft, are still at an impasse with this bootkit as they are unable to reliably detect it or protect even today’s fully patched machines from this type of attack. On the heels of that attack, another soon followed that involved a leak of sensitive information, such as private keys from multiple PC manufacturers. These private keys, typically used to cryptographically sign UEFI-based software, could potentially be used to create malicious software that can achieve very high-privileged access to the CPU. The bootkits plant malicious code onto the software that is both essential and highly trusted for normal operation of these devices.

In this blog post, which I adapted from my recent white paper, I will expand on the concerns brought to light from these attacks and highlight our recommendations to secure the UEFI ecosystem and restore trust in this piece of firmware. These recommendations will both raise awareness and help direct upcoming efforts to create a safer environment for computing.

Double Trouble: Baton Drop and Alder Lake

In October 2022, Kaspersky and SecurityWeek got early wind of the BlackLotus attack using UEFI to create bootkits. During these early stages, many critics, myself included, initially viewed these [rumblings] as unconfirmed accounts without enough evidence to qualify as threats to UEFI-based firmware. However, ESET later provided a detailed explanation of the attack and its ramifications. Then in the same month, the source code of the Intel Alder Lake processor, containing some of Intel’s BootGuard Platform keys, was leaked. These attacks exposed some of the challenges of the transitive trust we have from digitally signed software. Let’s take a look at these attacks in some detail.

Dropping the Baton

In January 2022, Microsoft published vulnerability CVE-2022-21894, which came to be called Baton Drop. The vulnerability stemmed from Microsoft’s signed bootloader software, a small piece of software that helps the OS load data during the boot process. The bootloader allowed memory truncation that could be abused to bypass the UEFI feature secure boot. This exploit broke one of the important links in the chain of trust that transitions from early boot stages to the OS. The vulnerable bootloader ideally should no longer be trusted. However, several implementations made this piece of bootloader essential to the boot process, making it impractical to replace or remove.

To add to the woes, a proof-of-concept attack software was provided for Baton Drop in a GitHub repository. Microsoft had no way to block this signed software without jeopardizing functional machines that depended on the vulnerable bootloader. With an exploit publicly available, Microsoft had to try to block the usage of this vulnerable bootloader using UEFI’s forbidden list. This approach proved difficult since the operational impact of blocking multiple versions of vulnerable bootloaders will impact many currently functional devices like laptops, desktops, and even enterprise-grade servers.

This event left a loophole that did not go unnoticed by attackers. With the BlackLotus bootkit, they soon took advantage of the vulnerability and used Microsoft's own trusted repository to download vulnerable signed software. They then built a series of attacks to undermine the trusted software validation. A resident bootkit could then be used to bypass the security chain of trust and run arbitrary software.

A Private Key is Stolen, Now What?

The leak of Alder Lake CPU source code revealed some private keys that were used for digitally signing software as trusted. Private keys present in the repository that can be used for debugging and specific tasks had now become available. In April 2023, it was reported that PC vendor Micro-Star International (MSI), in the wake of a ransomware attack, had their source code leaked and their network breached, adding even more private keys into the attacker’s precious collection. It was now possible to use some of these private keys and create signed malicious software that would have access to a very high-privileged mode of the CPU.

The solution for such a stolen key in the UEFI standard was strangely like the earlier case of the vulnerable bootloader: add it to the UEFI Revocation List, thus blocking all software from the compromised vendor. However, adding a private key to a Revocation List has a wide range of impacts, including potentially disabling a working or critical hardware module or device that was sourced from the forbidden vendor. This blocking could potentially impact any computer that has a supply-chain relationship to the forbidden vendor. In practical terms, it is not easy to audit many of today’s computers that lack a bill of materials to identify such vendors and their components.

A Forbidding Software Dilemma

The UEFI standard had developed defenses to threats posed by stolen private keys that can undermine the trust in UEFI-based firmware. However, these defenses were now being tested in real-world challenges to protect Windows PCs from attack. Let me quickly explore two major problems highlighting the complexity of these defenses.

UEFI’s Revocation List can contain multiple entries of various types, such as forbidden software, forbidden signature key, and forbidden device. However, software essential to the computer, such as bootloaders, cannot be blocked until every instance is replaced. The more widespread the software, as from major operating system or hardware vendors, the harder it is to replace.

The Revocation List is also all or nothing. There is no revision number or version of the Revocation List, and there is no way to customize it. In almost all its implementations, there is no way to dynamically check the Revocation List using the network or any other means to selectively disable a piece of software. This lack of customization means that IT managers will hesitate to add any software signed by a large-scale vendor to the Revocation List for a long time. To make the problems worse, the Revocation List is also limited in size due to the small storage available in the non-volatile firmware storage known as PCI Flash. This limitation makes it hard to keep this list growing as signed software is deemed as being vulnerable or risky.

Adding a vendor’s public key information to the Revocation List carries multiple consequences. It is estimated that any original equipment manufacturer (OEM) that sells a computer has direct control over less than 10 percent of the BIOS software. Computers are assembled with parts from multiple suppliers who, in some cases, assemble their parts from multiple suppliers. So goes the supply-chain tree, growing in complexity as our global economy finds the lowest price for these devices. It is hard to add a vendor entirely to the Revocation List without impacting certain parts of the computer that could potentially become unusable or unreliable. If such a vendor has provided critical components, such as network components, it may render the device unusable and unserviceable without physical access and reassembly. Finally, the system owners now face a challenge in how to manage the Revocation List and how to respond to a compromise of an international supplier.

Abandon UEFI or Rebuild?

So what actually went wrong with UEFI? Did the experts who created and updated the UEFI standard not see this coming? Clearly the threats against UEFI are in some ways greater than the UEFI standard alone can address. Fortunately, there are a variety of efforts to secure the UEFI firmware ecosystem. Probably the most definitive source for guidance on UEFI can be found in the NIST Platform Firmware Resiliency Guidelines (SP 800-193). While it is hard to predict the next threat and the goals of the adversary, UEFI ecosystem partners need only to fix the known unknowns in the UEFI firmware.

5 Recommendations for Securing the UEFI Ecosystem

Below I describe five recommendations for the UEFI ecosystem to reduce risk and defend against the threats outlined in this post. A recent white paper presents these recommendations in greater detail. This work also ties back to our earlier introductory blog on UEFI, where we captured some of our early concerns on this topic.

• Build a robust verification and attestation ecosystem. The current firmware verification and attestation should improve with newer technologies, such as dynamic verification and remote attestation, to ensure the software validation is advanced enough to survive new threats against UEFI.
• Improve the memory safety of critical UEFI code. Memory safety is crucial in pieces of low-level software that interact directly with hardware. Unlike the application-level software, there are no compensating controls for memory errors in firmware that pose risk to the device. It is critical that safe coding practices and tools to create memory-safe firmware components are readily available to the UEFI community, which involves all the members of the UEFI Forum, including nonvoting members.
• Apply least privilege and component isolation for UEFI code. Much of what we have learned from software development through the painful early years of vulnerable software seems not to have transitioned to UEFI development. The component isolation and the least-privilege principles should be applied, so UEFI software does not have untethered access and is treated much like any other software.
• Embrace firmware component transparency and verification. A software bill of materials (SBOM) is a crucial part of identifying software components and sources in a reliable way so that UEFI firmware also benefits from much needed clarity in this complex, connected supply chain of vendors.
• Develop robust and nonintrusive patching. UEFI software updates and patching are cumbersome and vary heavily between vendor implementations. The process is burdensome for users and IT system administrators, limiting their ability to routinely patch, update, and maintain these systems. Standards-based updates should be possible, with as little intrusion on the user as possible.

Securing UEFI Is Everyone’s Business

The UEFI standard is here to stay and is only expected to grow in its usage and adoption. It is therefore important for the many vendors and stakeholders that build and create UEFI-based software to actively embrace these challenges and respond to them collectively. System owners and operators are also urged learn about these challenges and expect their suppliers to secure UEFI from attacks. While we do not know how the threat landscape will evolve, we know about the gaps and threat motivators that have been highlighted here. It is imperative that the larger PC community engage in efforts that continually reduce risks and remove uncertainties associated with the usage of UEFI.