All Your Secrets Belong to Us: Leveraging Firmware Bugs to Break TEEs

All Your Secrets Belong to Us: Leveraging Firmware Bugs to Break TEEs

Speakers: Tom Dorman

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=ra-Ef1QykwY

Overview

In "All Your Secrets Belong to Us: Leveraging Firmware Bugs to Break TEEs," Tom Dorman delves into the critical security vulnerabilities residing within Trusted Execution Environments (TEEs), specifically targeting AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) technology. The talk exposes how firmware bugs, particularly within the highly privileged Platform Security Processor (PSP), can undermine the fundamental security guarantees of TEEs, leading to the leakage of sensitive secrets. This presentation is a deep dive into low-level hardware and firmware interactions, highlighting the intricate dance between CPU-enforced security mechanisms and the software components that manage them.

The core premise of TEEs like AMD SEV-SNP is to create isolated execution environments where applications and their data remain secure, even if the underlying operating system or hypervisor is compromised. This talk challenges that premise by demonstrating how flaws in the firmware responsible for managing these environments can be exploited. For TEEs, the speaker emphasizes that the leakage of secrets is often as detrimental as achieving arbitrary code execution, as stolen secrets can allow an attacker to impersonate the TEE and operate applications outside its protective confines.

Dorman's research underscores the continuous need for rigorous security analysis of complex hardware-software ecosystems. By focusing on AMD SEV-SNP, a technology designed to protect entire virtual machines from malicious hypervisors, the talk reveals a critical attack surface within the firmware components. The findings presented have significant implications for cloud providers, enterprises, and any entities relying on hardware-backed TEEs for sensitive workloads, stressing the importance of robust firmware security and the challenges of maintaining trust in such privileged components.

Background

▶ Watch: Introduction and talk agenda (0:00)

The concept of a Trusted Execution Environment (TEE) has emerged as a cornerstone of modern cybersecurity, aiming to establish a secure enclave within a main processor where applications can run with guaranteed confidentiality and integrity. The foundational idea is to protect sensitive workloads from a broader, potentially compromised software stack, including the operating system kernel or even the hypervisor in virtualized environments. This threat model is distinct from traditional security paradigms, prioritizing the prevention of information leakage above all else; for TEEs, an info leak is often considered as severe as arbitrary code execution, as it can directly compromise the TEE's purpose by revealing critical secrets that allow an attacker to bypass protections.

AMD's implementation of a TEE for virtualized environments is known as Secure Encrypted Virtualization (SEV), with its latest iteration being SEV-SNP (Secure Nested Paging). This technology is specifically designed to shield entire virtual machines (VMs) from an untrusted or malicious hypervisor. SEV-SNP achieves this by implementing hardware extensions directly within the CPU that ensure all memory owned by a protected VM is both encrypted and integrity protected. This prevents a hostile hypervisor from directly reading sensitive data or tampering with the VM's code and state. Furthermore, when an SEV-SNP VM is first booted, its initial memory contents are measured, and these measurements can later be verified through attestation reports, a mechanism akin to Trusted Platform Modules (TPMs), allowing remote verification of the VM's integrity.

Central to AMD SEV-SNP's security architecture is the Platform Security Processor (PSP). Analogous to Intel's Management Engine (ME), the PSP is a highly privileged, embedded processor found on all AMD CPUs. It operates independently of the main x86 cores, initiating system setup during early boot phases. In the context of SEV, the PSP serves as the root of trust, playing a crucial role in the lifecycle management of SEV-SNP VMs. This includes creating, deleting, migrating, and attesting VMs. The PSP also securely stores the cryptographic material essential for attestation, making its integrity paramount to the overall security of SEV-SNP. The SEV firmware, which runs on the PSP, is backwards compatible with earlier SEV and SEV-ES versions and can be live-updated, with significant portions of it being publicly released by AMD in August 2023, enabling deeper security research.

A key mechanism for memory integrity protection within SEV-SNP is the Reverse Map Table (RMP). This large, hardware-managed table tracks the ownership and state of every 4-kilobyte chunk of memory on the system. Initially, most memory is owned by the hypervisor, which can then assign pages to VMs. Before every memory write operation, the CPU internally consults the RMP to verify that the entity performing the write (e.g., a guest VM or the hypervisor) is indeed the legitimate owner of that memory page. This automatic, hardware-enforced check is designed to prevent unauthorized access and tampering between guests, or by the hypervisor against a guest. The RMP is managed through two primary methods: simple memory assignments are handled by special CPU instructions, while more complex operations like memory swapping or movement require interaction with the SEV firmware running on the PSP. Critically, while the CPU automatically enforces RMP checks for all access levels, including hypervisor and System Management Mode (SMM), the highly privileged PSP firmware, in principle, can write to any memory location. Therefore, the security of the entire system hinges on the PSP firmware diligently performing its own manual RMP access checks. This reliance on firmware-level checks, as foreshadowed by the speaker, becomes the focal point of the vulnerabilities discussed.

Key Findings

▶ Watch: Overview of AMD SEV SNP technology (2:00)

The central revelation of this talk is the identification of a critical vulnerability class within AMD SEV-SNP's trusted execution model, specifically stemming from the Platform Security Processor (PSP) firmware's handling of Reverse Map Table (RMP) checks. While the CPU hardware itself rigorously enforces RMP rules for memory access, the highly privileged PSP firmware, which is responsible for complex memory management operations for SEV-SNP, does not always correctly implement or enforce these checks manually. This discrepancy creates a significant bypass, undermining the integrity and confidentiality guarantees that SEV-SNP is designed to provide.

The speaker outlines that the SEV firmware, executing on the PSP, is tasked with managing intricate memory operations that go beyond simple page assignments. These include scenarios like memory swapping or remapping, where the firmware must access and modify memory pages that might be owned by protected guest VMs. Although the PSP is inherently privileged enough to write to any memory location, it is expected to perform its own internal RMP-like checks to ensure it only interacts with memory it legitimately owns or is authorized to modify. The core finding is that these manual firmware-level RMP checks can be flawed or altogether missing in certain critical execution paths.

While the specific details of "our first bug" and "a second bug" mentioned in the talk's outline are not explicitly detailed within the provided transcript, the overarching finding is clear: an attacker (specifically, a malicious hypervisor) can exploit these firmware vulnerabilities to bypass the RMP's integrity protections. This allows the hypervisor to write to memory pages that are supposedly owned and protected by an SEV-SNP guest VM. Such unauthorized writes lead directly to the compromise of the VM's integrity and, critically, its confidentiality. The ultimate impact is the leakage of secrets, which, as emphasized, is tantamount to arbitrary code execution in the TEE threat model, enabling an attacker to impersonate the TEE or run protected applications outside their secure environment. The discovery highlights a fundamental weakness in the trust boundary between the secure hardware and the firmware that orchestrates its complex operations.

Technical Deep Dive

▶ Watch: The Platform Security Processor (PSP) in SEV (3:20)

AMD's Secure Encrypted Virtualization-Secure Nested Paging (SEV-SNP) aims to provide robust protection for virtual machines against a malicious hypervisor. This is achieved through a combination of hardware-backed memory encryption and integrity protection, managed by the Platform Security Processor (PSP) and its associated firmware. The technical deep dive into this architecture reveals the critical points of failure identified in the talk.

At the heart of SEV-SNP's memory integrity is the Reverse Map Table (RMP). The RMP is a massive data structure, maintained in hardware, that tracks the ownership status of every 4-kilobyte page of physical memory in the system. Each RMP entry signifies whether a page is owned by the hypervisor, a specific guest VM (identified by its Address Space ID - ASID), or the firmware itself. The CPU enforces RMP checks automatically: whenever any entity attempts to write to a memory page, the CPU consults the RMP to verify ownership. If the writing entity does not own the page, the write is blocked, preventing unauthorized tampering. This mechanism is fundamental to preventing a hypervisor from directly altering a guest's memory.

However, the PSP operates at a higher privilege level than the CPU's standard execution contexts, including the hypervisor and even SMM (System Management Mode). The PSP, being the root of trust for SEV-SNP, has the theoretical capability to access and modify any memory location. To maintain the security model, the PSP firmware is designed to perform its own internal access checks, mimicking the RMP's functionality, before writing to memory. This is particularly crucial for complex memory management operations, such as memory swapping or live migration, where the PSP firmware must interact with memory pages that are assigned to and protected by guest VMs.

The vulnerability arises precisely at this juncture: the PSP firmware's manual RMP checks are not always correctly implemented or are entirely absent for certain operations. The transcript highlights that while the CPU automatically enforces RMP for all privilege levels, this is "not always the case" for the firmware. The PSP, by virtue of its high privileges, can write to any memory, but it should only write to memory it owns or has been explicitly granted access to. When the firmware fails to perform these checks diligently, a malicious hypervisor can leverage this flaw.

Consider the typical interaction workflow between the hypervisor and the SEV firmware for memory management:

1. The hypervisor writes a request (e.g., to move or swap a memory page) into a designated memory region.
2. The hypervisor "donates" this request page to the firmware, typically by changing its RMP ownership.
3. The hypervisor notifies the firmware about the request.
4. The firmware reads the request from the designated memory page.
5. The firmware processes the request, which might involve modifying other memory pages.
6. The firmware writes the response back to a memory page.
7. The firmware notifies the hypervisor it's done.
8. The hypervisor reads the response.
9. The hypervisor reclaims the pages.

The critical vulnerability point occurs during step 6, when the firmware writes its response or performs other memory modifications as part of processing the request. If the firmware, in its highly privileged state, attempts to write to a memory page that is owned by a protected guest VM without first verifying its right to do so via internal RMP checks, then the hypervisor (which initiated the request) can effectively trick the firmware into performing an unauthorized write. This allows the hypervisor to inject malicious data or alter the state of a protected VM's memory, bypassing the fundamental integrity protections of SEV-SNP.

The transcript implicitly refers to this mechanism when it states, "During step 6, the firmware needs to check whether it's allowed to write to memory." The failure of these checks is the core technical flaw. By exploiting such a bug, an attacker can manipulate the guest's context, potentially leading to control over the guest's execution flow or the extraction of its cryptographic secrets. The ultimate outcome is a complete subversion of the TEE's security guarantees, transforming a theoretically secure environment into one vulnerable to a compromised hypervisor.

Demo / Proof of Concept

▶ Watch: Reverse Map Table (RMP) for memory integrity (4:30)

While the comprehensive, step-by-step methodology of the demonstrated exploit was not fully detailed in the provided transcript, several key snippets strongly indicate a successful Proof of Concept (PoC) that leverages the identified firmware vulnerabilities to compromise AMD SEV-SNP's protections. These fragments point towards a sophisticated attack chain involving the manipulation of guest VM state and cryptographic material.

The transcript mentions "Corrupt guest context page so that ASID is in range 1..510." This suggests a direct manipulation of a VM's internal state, specifically targeting its Address Space ID (ASID). The ASID is a unique identifier assigned to each SEV-SNP VM, crucial for the RMP to distinguish memory ownership. Corrupting the guest context page to force the ASID into a specific range (1-510) likely aims to either:

1. Bypass RMP checks: By manipulating the ASID, the attacker might trick the firmware or CPU into misattributing memory ownership, allowing unauthorized writes.
2. Facilitate a side-channel or brute-force attack: A controlled ASID range might simplify subsequent steps, perhaps by making certain memory regions predictable or by enabling a more targeted search for sensitive data.

Further evidence of a practical exploit is given by the statistical and timing data: "Smallest ASID: 0x0000001f iterations: 14052175 zeroes: 10539628 unique asids: 31500727 elapsed time: 1d 19h 20m 31s." This segment strongly indicates a lengthy, potentially brute-force or exhaustive search component within the PoC. The large number of iterations and unique ASIDs, coupled with an execution time exceeding a day, suggests an attack that systematically probes or searches for specific states or vulnerabilities. This could involve:

• Searching for a vulnerable ASID state: Identifying an ASID that, when combined with a firmware bug, allows for specific memory access.
• Key derivation or recovery: Attempting to derive or recover cryptographic keys by observing patterns or manipulating states across a wide range of ASIDs.
• Exploiting non-deterministic behavior: Leveraging timing differences or other side effects of the firmware bug across numerous attempts to gain information.

Crucially, the phrase "Creating VM with identical UMC key seed" signifies the ultimate goal and success of such an exploit. The Unified Memory Controller (UMC) key seed is a foundational cryptographic component used to derive the encryption keys for VM memory. If an attacker can create a new VM using an identical UMC key seed as a target VM, it implies they have either extracted the original key seed or successfully manipulated the system to generate a duplicate. Possessing the UMC key seed effectively breaks the confidentiality of the target VM, allowing the attacker (hypervisor) to decrypt all its memory contents. This directly achieves the talk's stated primary threat: leakage of secrets, enabling full compromise and impersonation of the TEE.

The "Raw page" snippet further suggests the ability to read or dump encrypted memory after the compromise, confirming the leakage of data. While the exact firmware bug used to achieve the guest context corruption and subsequent key seed duplication is not detailed in the transcript, the presented output clearly demonstrates that the security boundaries enforced by AMD SEV-SNP were successfully breached, allowing a malicious hypervisor to gain unauthorized access to a protected VM's secrets. This PoC validates the critical nature of the identified firmware vulnerabilities.

Defensive Implications

▶ Watch: RMP management and potential vulnerabilities (6:08)

The findings presented in this talk carry profound defensive implications for anyone relying on AMD SEV-SNP, particularly cloud providers and enterprises deploying sensitive workloads in virtualized environments. The core takeaway is that hardware-backed TEEs, while offering significant security enhancements, are not infallible, and their security posture is critically dependent on the integrity and correctness of their underlying firmware.

1. Prioritize Firmware Updates: The most immediate defensive action is to ensure that AMD SEV-SNP enabled systems are running the latest available firmware. Vulnerabilities like those discussed are typically patched by hardware vendors through firmware updates. Organizations must establish robust patch management processes for platform firmware, treating it with the same criticality as operating system or application security updates. Given the PSP's role as the root of trust, any vulnerability in its firmware can undermine the entire security chain.

1. Rethink Trust Boundaries: The talk highlights that even highly privileged firmware components, like the PSP, can introduce vulnerabilities if their internal access control mechanisms (e.g., manual RMP checks) are flawed. Defenders should understand that the trust boundary extends beyond the CPU's hardware-enforced checks to include the firmware's software-driven logic. This necessitates a more skeptical approach to TEE security, recognizing that the "trusted" component itself can become a vector for attack if its code is not perfectly secure.

1. Enhanced Security Research and Auditing: The public release of SEV firmware parts by AMD in August 2023 was crucial for this research. This underscores the value of transparency and community-driven security research. Defenders should advocate for continued transparency from hardware vendors regarding TEE firmware, as external scrutiny is vital for identifying complex, low-level bugs that might be missed internally. For organizations with the capability, internal security auditing of firmware, if possible, should be considered.

1. Layered Security and Defense in Depth: While TEEs provide a strong foundational layer of security, they should not be seen as a silver bullet. Organizations should continue to implement layered security measures, including strong network segmentation, application-level security, and robust access controls, even for workloads running within TEEs. This ensures that if a TEE's protections are compromised, other layers of defense can still mitigate the impact.

1. Attestation Verification and Monitoring: Attestation reports are designed to verify the integrity of a VM's initial state. However, if the PSP firmware itself is compromised, it could potentially falsify attestation reports or allow a VM to boot into a compromised state while still reporting as "secure." Defenders must ensure their attestation verification processes are robust and consider monitoring for unusual attestation report patterns or failures, which could indicate a deeper compromise.

1. Supply Chain Security: Firmware vulnerabilities underscore the importance of securing the entire supply chain. From silicon design to platform integration, every step is a potential point of compromise. Organizations should engage with vendors who demonstrate strong security practices throughout their development and manufacturing processes.

In essence, the talk serves as a stark reminder that the security of complex hardware-software systems is only as strong as their weakest link. For TEEs, that weakest link can often be the privileged firmware components that orchestrate their operation, demanding continuous vigilance and proactive security measures from defenders.

Key Takeaways

• Firmware is a Critical Attack Surface: Despite hardware-enforced security mechanisms like the RMP, the highly privileged Platform Security Processor (PSP) firmware in AMD SEV-SNP presents a significant attack surface. Flaws in its manual access checks can bypass CPU-level protections.
• Leakage of Secrets is Paramount: For TEEs, the primary threat is the leakage of sensitive data. Exploiting firmware bugs to access encrypted memory or derive cryptographic keys directly undermines the core purpose of a TEE, allowing attackers to impersonate secure environments.
• RMP Checks are Not Always Consistent: While the CPU automatically enforces Reverse Map Table (RMP) integrity checks for all memory writes, the PSP firmware, due to its elevated privileges, must perform its own manual checks. Vulnerabilities arise when these manual checks are incomplete or incorrect.
• Complex Memory Operations Pose Risk: Operations like memory swapping or migration, which require the SEV firmware to interact with guest-owned memory, are particularly vulnerable points if the firmware's internal access controls are not robust.
• Attestation Can Be Undermined: A compromised PSP firmware could potentially affect the integrity of attestation reports, making it difficult to verify the true security state of a protected VM.
• Continuous Research and Updates are Essential: The ability to research SEV firmware (partially open-sourced by AMD) is vital for uncovering such vulnerabilities. Timely application of vendor-provided firmware updates is critical for mitigating these risks in production environments.

About the Speaker(s)

The talk "All Your Secrets Belong to Us: Leveraging Firmware Bugs to Break TEEs" was presented by Tom Dorman. Based on his self-introduction, Tom is passionate about low-level systems security, expressing a strong interest in direct hardware interaction and a dual enjoyment for both writing and breaking code. His expertise clearly lies in deeply technical areas, specifically focusing on the intricate interactions between hardware and firmware components that underpin modern security technologies.