In today’s computing environment, firmware can mean several things, ranging from an entire operating system in embedded devices to a small flash program in a hardware component that tells your operating system (OS) about that hardware’s capabilities. In this blog post, we will focus on the vulnerabilities in the latter type of firmware popularized by the Uniform Extensible Firmware Interface (UEFI). I will explore how these vulnerabilities are a lucrative target for high-profile attackers, such as nation-states that are seeking vulnerabilities in the less-visible portions of today’s computing environment.

First, to get our footing, it is important to understand what UEFI really is. UEFI replaces the legacy Basic Input/Output System (BIOS), interfacing hardware to the OS and provides an extensible intersection between hardware and the OS itself. The UEFI standard also identifies reliable ways to update this firmware from the OS. In essence, in today’s computers, there is another layer of software that can help the OS understand and use available hardware. Of course, this essential layer of software faces all the challenges of today’s software: bugs, security issues, patching, and maintenance. It also lacks visibility, making it hard for defenders to protect this part of their computing environments from ever-increasing threats.

Moods of your CPU: Real, Protected, and System Management

The Intel CPU architecture defines several modes in which the CPU operates to interpret, execute, and satisfy the tasks requested by the OS. In most modern operating systems, protected mode provides for secure operations of tasks with capabilities, such as memory isolation between processes. Intel also provides a system management mode (SMM), which is a highly privileged mode of operation accessible to the OS via the specific System Management Interrupt (SMI) handler. SMM is the primary mode in which UEFI operates to interface directly with the hardware. Typically, a single master SMI handler will allow for registration and management of other SMI handlers, which are all identified by their globally unique identifiers (GUIDs).

What Can Be Smaller than 0? Well –2 Maybe?

In computer science, protection rings are used to identify various levels of privileged access to resources on your computer. Ring 0 is typically considered to be the highest level of access available to a system-level user of an OS. However, hidden rings (Ring –1 for hypervisor and Ring –2 for SMM) are essentially required to perform tasks with privileges greater than the OS itself. These include tasks such as configuring or modifying the configuration of the hardware or adding new software-based capabilities to an already present hardware device.

In certain cases, there are also things, such as UEFI variables, that provide important data used throughout the OS boot process. The UEFI standard spells out specifications for SMI handlers, which are basically software written to achieve system calls to request the CPU to perform tasks in the high privilege mode called SMM. Vulnerabilities exist both in the programming of the SMI handler and in properly defining (and protecting) UEFI variables. Those actors who can exploit these vulnerabilities are provided with a high privilege mode to execute their code on a targeted computer.

Software Means Vulnerabilities

As UEFI capabilities are developed, more and more capability is delegated to the UEFI software to allow it to modify, customize, and in some cases, enhance currently available hardware capabilities of a computer. Most of this software is written in lower-level languages (mostly C) that require careful use of resources, such as memory. All the operations in SMM are kept in a protected area of memory called SMRAM, which is isolated from the operating system. The communications initiated by the SMI handlers are abstracted using a communications buffer dubbed CommBuffer. SMRAM also has specific code segments (non-writeable) and data segments (non-executable), which are all invoked from the OS using a CommBuffer.

Today, software expected to run with SMM’s privileged mode is provided by several vendors and ends up being assembled by an OEM PC vendor before a computer is sold in the market. The majority of this software is derived from the example community-developed project called Tianocore that provides software development kits (SDK) called EDKII for building these UEFI modules. EDKII is example code that requires careful security review, especially of memory management, before being implemented for specific use cases. Many well-known C coding errors (e.g., unsafe pointers, proper pointer validation, type confusion, and improper locking) can be easily introduced while developing UEFI software. These defects lead the software to disclose SMRAM contents, corrupt the SMRAM payload, hijack the SMM code flow, and finally, enable the writing arbitrary code/content to the Serial Peripheral Interface (SPI) Flash. As a combined effect, these errors give the attacker a powerful way to write permanent code on the device in a most obscure location.

The platform-initialization phase diagram from the EDKII Build Specification repository provides some detailed information on how a modern computer goes through its boot process. UEFI provides immense capabilities to initiate, configure, and customize the way in which hardware will be used when the computer is operating in normal conditions. This powerful capability is now being explored by both security researchers and attackers.

As an example, researchers Assaf Carlsbad and Ittai Liba from Sentinnel One disclosed the ability to break secure boot to compromise one of the earliest phases of platform initialization. The researchers demonstrated the exploitation of multiple weaknesses starting from a lack of validation of SMRAM contents due to nested pointers to overwrite the secure-boot configuration. In another recent disclosure, researcher Alex Matrsov from Binarly disclosed a number of SMI handlers that primarily allow privilege escalation in the Drive eXecution Environment (DXE) phase that can lead to arbitrary code execution in high SMM privilege mode of the CPU. These attacks can also be initiated as your computer is reawakened from sleep mode. The systemic errors discussed above make each and every phase in the boot process vulnerable to attack.

Why Attack the SMM?

Should we be concerned about these vulnerabilities? Do attackers really want to go through thousands of UEFI implementations to find vulnerabilities? SPI Flash communications is very slow compared to today’s common attacks, which target memory and disk as locations for permanence or persistence. Will attackers target such a slow SPI interface for attacks? Below are just some of the reasons why attackers find UEFI implementations to be an attractive target for attacks:

• SMM as the high ground—SMM offers the attacker highest privilege mode of a CPU, almost unguarded even by the operating systems (Ring 0), hypervisor (Ring –1), and any security software including endpoint detection and response (EDR) in today’s computing environments.
• P is for persistence in APT—The attacker today is looking for persistence that will survive rebuilding of the operating system. What better place is available than the SPI flash? Basically the BIOS location. Lojax and Sednit, for example, target SPI flash for persistence.
• Invisibility—As shown by MoonBounce, an implant written as a UEFI firmware module can work in stealth leaving no trace for the OS or sometimes even the network.
• A broken vulnerability lifecycle—Many firmware vulnerabilities either are not addressed, or they reappear several years after discovery. Complex supply chain and poor firmware update cycles make UEFI firmware an ideal target for attackers to consider when developing implants.

What Should We Do?

Several efforts are already underway in research and industry to improve UEFI security. Here are a few efforts that we would like to become involved in.

• Best practices and better tools for UEFI development—The EDKII specification and a sample implementation have been very powerful in onboarding a number of small companies for UEFI development. However, a number of secure coding practices and audits are needed to ensure that code is protected against typical abuse of memory primitives in these low-level programs. Research and effort are needed to secure the code by default limiting SMRAM abuse. There is also a need for DevSecOps-like efforts to ensure that the firmware development lifecycle is secured at its very beginning.
• SBOM and transparency-—Much of the UEFI development and production of UEFI modules and firmware have been performed privately by several vendors of the supply chain called independent BIOS vendors (IBV), independent hardware vendors (IHVs), and original device manufacturers (ODMs). The majority of these software modules are protected by proprietary storage and compression techniques, which provide very low visibility to customers and sometimes even to the OEMs that package and resell the software. The UEFI firmware space needs a transparent and accountable software bill of materials (SBOM) with sufficient detail to support accountable disclosure of components and vulnerability management of these components.
• Tools to analyze UEFI images, modules, and capsules—Somewhat related to the earlier concern of transparency, much of the UEFI code is opaque and sometimes even obfuscated by their vendors. We therefore need more transparent tools to analyze and audit UEFI firmware developed either as a source code or as binary static code analyzers to identify code flow and potential abuse of intended UEFI standards-based communications and executions. Today only a few software tools, such as Chipsec, allow the dumping of ROM EFI images. Some reverse-engineering tools, such as Sentinel’s Brick and Binarly’s efiXplorer, exist to analyze UEFI software modules. The scarcity of such tools limits the amount of community analysis and insight needed to discover and address security concerns in UEFI software.
• Timely vulnerability lifecycle management—UEFI firmware vulnerabilities discovery, responsible disclosure of these vulnerabilities, and timely software updates to address these vulnerabilities will all need to be improved. Capabilities, such as automatic updates and capsule-based updates, should be commonplace to ensure that UEFI updates are not cumbersome or confusing for the consumers and users of computing environments. Efforts, such as Microsoft’s Firmware Update Platform and Linux Vendor Firmware Service (LVFS) projects, attempt to solve this by providing a secure way to update firmware capsules using a standards-based approach. LVFS in particular provides an open-source, transparent way to address this issue by reducing the burden of delivering the firmware updates on vendors. OEM vendors are urged to actively participate in such efforts to ensure timely update of vendor firmware modules.

Addressing Systemic Classes of Vulnerabilities

At the SEI’s CERT Division, we see UEFI security as closely related to our research in addressing systemic classes of vulnerabilities. We would like to partner and support your efforts by providing support for timely disclosure, better analysis, and a swift response to vulnerabilities in the UEFI software ecosystems. If you are interested in working with us, please email info@sei.cmu.edu.