AMD Sinkclose-Universal Ring2 Privilege Escalation

AMD Sinkclose-Universal Ring2 Privilege Escalation

Speakers: Enrique Nissim; Krzysztof Okupski

Conference: DEF CON 32

YouTube: https://www.youtube.com/watch?v=kEIJFsOgEBY

Overview

This talk, "AMD Sinkclose-Universal Ring2 Privilege Escalation," delivered by Enrique Nissim and Krzysztof Okupski at DEF CON 32, reveals a critical architectural flaw present in AMD processors for at least 18 years. The presentation details a novel method to achieve Ring2 privilege escalation to System Management Mode (SMM), the most privileged execution environment on an x86 system. This vulnerability, dubbed "Sinkclose," exploits an overlooked configuration bit in AMD's TSEG Mask register to redirect SMM data accesses, ultimately leading to arbitrary code execution within SMM.

The significance of this discovery cannot be overstated. SMM operates at a privilege level even higher than the operating system (Ring0) and hypervisors, making it a prime target for sophisticated attackers seeking stealthy, persistent, and undetectable control over a system. Code executing in SMM is hidden from standard security solutions like antivirus software, Endpoint Detection and Response (EDR) tools, and anti-cheat engines, rendering traditional defenses ineffective. The speakers demonstrate how this architectural flaw allows an attacker to achieve persistent firmware modification, highlighting a profound vulnerability in the foundational security of AMD-based platforms.

Background

▶ Watch: Introduction to SMM and its hidden nature (0:00)

To understand the severity of the Sinkclose vulnerability, it's essential to grasp the fundamentals of System Management Mode (SMM). SMM is a special CPU operating mode on x86 architectures, designed to handle system-wide functions such as power management, security, and hardware configuration. It runs at the highest privilege level, effectively below Ring0 (OS kernel) and hypervisors. SMM code, typically part of the platform firmware (BIOS/UEFI), is loaded into a protected memory region called System Management RAM (SM RAM) during boot time. Once loaded, the system hands off execution to the OS loader, but SMM remains active, providing services that the OS can invoke via System Management Interrupts (SMIs).

The security of SM RAM is paramount. When the CPU is in normal (non-SMM) mode, access to SM RAM is strictly controlled by the memory controller. Reads from SM RAM should return all 0xFFs, writes should be discarded, and execution disallowed. This protection is primarily enforced by the Top of Memory Segment (TSEG) region. Firmware configures two key registers: TSEG Base and TSEG Mask. The TSEG Base specifies the starting address of the SM RAM region, while the TSEG Mask defines its length and includes a T Valid bit to enable the protection. The idea is for this region to overlap and protect all contents of SM RAM.

A crucial security mechanism in SMM is the SMM Lock bit. This bit, typically set by the firmware during boot, prevents the operating system (running at Ring0) from tampering with SMM-related registers at runtime. Without this lock, an attacker with Ring0 privileges could potentially disable TSEG protection, allowing them to modify SM RAM contents and execute arbitrary code in SMM.

The speakers noted a significant architectural difference between Intel and AMD regarding Model Specific Registers (MSRs) related to SMM. On Intel systems, these MSRs are generally only accessible when the processor is already in SMM. Accessing them from normal mode, or even obtaining the SMM base address, can be considered a security leak. However, on AMD platforms, all SMM-related MSRs are accessible from Ring0, even if the SMM Lock bit is set. While accessibility doesn't immediately imply configurability (if locked, changes are prevented), it means an attacker can read the configuration, which proved crucial for discovering this flaw. The researchers' prior work in 2023 involved identifying CVEs related to vendor misconfigurations or software vulnerabilities in SMM components, but Sinkclose represents a deeper, architectural issue within the AMD processor itself.

Key Findings

▶ Watch: How TSEG region protects SMM memory (3:00)

The core discovery presented by Nissim and Okupski is an architectural flaw in AMD processors stemming from an oversight in the TSEG Mask register documentation and implementation. While the SMM Lock bit is intended to protect SMM-related MSRs from modification by the OS, two specific fields within the TSEG Mask register—T Close and A Close—are not covered by this lock. This means an attacker with Ring0 privileges can modify these bits at runtime, even when SMM is locked.

The T Close bit is the primary focus of the exploit. When this bit is set, the processor's behavior changes dramatically when it enters SMM: data accesses are redirected to Memory-Mapped I/O (MMIO) space instead of SM RAM. Instruction fetches, however, continue to be directed to DRAM (SM RAM). This creates a "Harvard-like" architecture within SMM, where instruction and data paths diverge. The A Close bit is a similar feature for an older region called A seg, which overlaps with video memory and is no longer relevant in modern systems.

The purpose of the T Close feature, according to AMD documentation from 2006, was to allow SMM code to access an I/O device that reuses the same physical address space as SM RAM. However, the speakers reported not having observed any vendors actually using this feature. The fact that this bit has existed and been exploitable for at least 18 years (since its documentation appeared) underscores the long-standing nature of the vulnerability.

Triggering the initial condition is straightforward: setting the T Close bit from Ring0 and then invoking an SMI immediately causes the system to freeze or hang. This behavior is due to SMM attempting to access its safe state area (where processor registers are saved during an SMI) from MMIO, which is typically unmapped or contains unexpected values, leading to instability.

The initial attack strategy involved using the SPI controller, a device present in all tested AMD systems, primarily used for accessing the SPI flash. The SPI controller's Base Address Register (BAR) could be relocated to overlap with the SMM entry point of core zero. By manipulating values within this BAR at a specific offset (0x4D), the attackers aimed to create a fake Global Descriptor Table (GDT). The idea was that when the SMM entry point code executed with T Close enabled, the LGDT instruction (which loads the GDT register) would read from the attacker-controlled SPI BAR, pointing the processor to the fake GDT and allowing arbitrary code execution.

However, this initial approach failed due to memory access priorities. The speakers discovered that the TSEG/Aseg SMM mechanisms have lower priority than certain other memory regions, including Top of Memory (TOM). MMIO configuration space and the Advanced Programmable Interrupt Controller (APIC), which were considered as alternative devices, had higher priority. The APIC, while higher priority, proved unusable due to system instability when moved and its registers at offset 0x4D not being suitable for controlling the GDT.

The breakthrough came from an integer overflow vulnerability during the SMM entry point's transition from real mode to protected mode. This critical phase involves loading the GDT via the LGDT instruction. When T Close is enabled, and no device is mapped to the memory region where the GDT is expected, the processor reads all 0xFFs. If the GDTR register is loaded with 0xFFFFFFFF..., a subsequent far jump with a segment selector (e.g., 0x8) causes an integer overflow. This overflow effectively wraps the address around to a very low physical address, such as 0x7, which resides in DRAM. Since DRAM is controllable by the operating system, the attacker can place their fake GDT at this specific low physical address, gaining control over SMM execution. This ingenious bypass of memory priorities and MMIO mapping issues formed the foundation of the successful exploit.

Technical Deep Dive

▶ Watch: Key difference: Intel vs. AMD SMM MSR access (5:25)

The technical core of the Sinkclose attack hinges on manipulating the processor's state during the critical SMM entry sequence. When an SMI occurs, the processor immediately saves its current register state into a designated "safe state" area within SM RAM. The processor then enters SMM, starting execution in real mode (16-bit). The initial SMM entry point code is responsible for quickly transitioning the processor through protected mode (32-bit) to long mode (64-bit) before handing off to the actual SMI handlers.

The transition from real mode to protected mode is crucial, as it involves enabling segmentation. Segmentation is an x86 memory management scheme that divides memory into logical segments, each with specific attributes like base address, limit, and access permissions. The Global Descriptor Table (GDT) is a key data structure containing these segment descriptors. A processor register, GDTR, stores the base address and limit of the GDT. The LGDT instruction is used to load the GDTR.

The architectural flaw exploits the behavior of the T Close bit within the TSEG Mask MSR. As established, setting T Close from Ring0 redirects SMM data fetches to MMIO space, while instruction fetches continue from SM RAM. When an SMI is triggered with T Close set, the initial SMM entry point code begins executing. During the LGDT instruction, the processor attempts to read the GDT structure. Because T Close is active, this data read is directed to MMIO.

The critical insight from the researchers was realizing that if the MMIO region where the GDT is expected is not mapped to a device, the processor will read all 0xFFs. This results in the GDTR being loaded with a base address of 0xFFFFFFFF... and a limit of 0xFFFFFFFF.... Following the LGDT instruction, the SMM entry code typically performs a far jump to transition to protected mode. A far jump uses a segment selector (e.g., 0x8 for a code segment). The effective physical address for the jump is calculated by adding the segment selector to the base address stored in GDTR.

Here, the integer overflow comes into play. If the GDTR base is 0xFFFFFFFF... and a segment selector like 0x8 is added, the 32-bit arithmetic operation overflows, resulting in a very low physical address, often 0x7 (e.g., 0xFFFFFFFF + 0x8 = 0x100000007, truncated to 0x7 in a 32-bit context for the segment base, or similar logic for the descriptor table entry lookup). This address 0x7 resides in DRAM, which is entirely controllable by the operating system (Ring0).

Therefore, the attacker, after enabling T Close, can pre-position a malicious fake GDT at a low physical address in DRAM (e.g., 0x7). When the SMM code triggers the integer overflow and attempts to read segment descriptors from this address, it will instead load the attacker's fake GDT. This fake GDT can contain descriptors that point to arbitrary code at an attacker-chosen base address, effectively redirecting SMM execution to the attacker's payload.

To achieve this, the researchers leveraged the SPI controller. The SPI controller is chosen because it's ubiquitous on AMD systems and, crucially, its Base Address Register (BAR) can be relocated. While the initial idea was to map the SPI BAR directly over the SMM entry point to control the GDT, the revised strategy uses the SPI controller's BAR to map a device somewhere in MMIO that, when read by the LGDT instruction, will return specific values (or 0xFFs if unmapped) to induce the integer overflow. Specifically, the SPI controller allows the attacker to control values at offset 0x4D within its BAR. This control over MMIO allows the attacker to orchestrate the conditions for the LGDT instruction to load a GDTR that eventually leads to the integer overflow into DRAM. The SPI controller itself is not directly providing the fake GDT, but it provides the mechanism to interact with MMIO in a way that creates the 0xFF scenario for the LGDT instruction, thus enabling the integer overflow.

The challenge of multi-core systems was also addressed. When an SMI is triggered, the I/O hub typically sends the SMI to all cores simultaneously. If T Close is enabled on all cores, and one core attempts to save its state to MMIO that is not properly mapped, it will read 0xFFs for its safe state, and writes will be dropped. This often leads to a triple fault and a system crash. The integer overflow technique elegantly bypasses this, as the GDT is placed in shared DRAM, and the overflow behavior is consistent across cores (though the exploit typically targets a single core for controlled execution). This robust method allows the attacker to gain control over SMM on a chosen core without crashing the system.

Demo / Proof of Concept

▶ Watch: T close diverts SMM data accesses to MMIO (7:20)

The speakers demonstrated a compelling proof of concept (PoC) of the Sinkclose vulnerability. The exploit was designed to run with kernel privileges, typically via a malicious driver. The attack sequence involved three main steps:

1. Elevate Privileges to SMM: The malicious driver first triggers the Sinkclose vulnerability by setting the T Close bit in the TSEG Mask MSR from Ring0. It then invokes an SMI, causing the targeted core to enter SMM. Due to the integer overflow mechanism detailed in the technical deep dive, the attacker's fake GDT in DRAM is loaded, redirecting SMM execution to the attacker's payload.
2. Disable SPI Flash Protections: Once arbitrary code execution is achieved in SMM, the payload disables any protections on the SPI flash. The SPI flash is critical as it stores the platform firmware (BIOS/UEFI), including boot logos and other sensitive configuration data.
3. Write to SPI Flash: The SMM payload then writes a custom image to the portion of the SPI flash where the boot splash logo resides. This demonstrates persistent modification of the system firmware.

The demonstration showed the exploit running, indicating "Done patching" after a period (which was fast-forwarded in the video, noting it typically takes about 15 minutes). Following a system reset, the custom boot splash logo appeared, confirming the successful SMM privilege escalation and persistent firmware modification. This PoC effectively showcased the full impact of the Sinkclose vulnerability, from Ring0 to SMM privilege escalation and beyond, to persistent platform compromise.

Defensive Implications

▶ Watch: Triggering T close causes immediate system freeze (8:00)

The Sinkclose vulnerability highlights a critical need for robust firmware security and careful architectural design in modern processors. For defenders, the implications are significant:

1. Firmware Updates are Paramount: The primary defense against this architectural flaw is a microcode update from AMD, deployed through firmware (BIOS/UEFI) updates provided by system vendors. While the speakers stated they did not officially know the exact changes made by AMD, it is implied that a fix has been released. Users and organizations must prioritize applying these updates promptly to mitigate the risk.
2. MSR Access Control: The vulnerability stems from the ability to modify critical SMM-related MSRs (specifically, the TSEG Mask register's T Close bit) from Ring0, even when the SMM Lock bit is set. This underscores the importance of strict MSR access control. Hypervisors, such as the one on the PlayStation 5 mentioned in the Q&A, that block MSR access can inadvertently provide a layer of protection against this specific attack vector.
3. SMM Hardening and Auditing: Firmware developers must ensure that all SMM-related registers are correctly locked down by the SMM Lock bit at boot time. This incident serves as a stark reminder that even seemingly minor oversights in bit-level register protection can lead to severe architectural vulnerabilities. Regular and thorough security audits of firmware code, particularly around SMM initialization and protection mechanisms, are crucial.
4. Supply Chain Security: Since this attack enables persistent firmware modification, it underscores the importance of a secure supply chain. Ensuring that firmware images are legitimate, untampered, and up-to-date from trusted sources is vital. Technologies like Secure Boot can help detect unauthorized firmware modifications, but the SMM escalation itself happens at a layer below what Secure Boot typically protects during runtime.
5. Detection Challenges: Detecting SMM exploits like Sinkclose is inherently difficult. Code running in SMM operates outside the visibility of the operating system, hypervisor, and most security software. This "invisible" nature makes it a highly attractive target for advanced persistent threats (APTs). Advanced hardware-based monitoring or trusted execution environments might offer future avenues for detection, but these are complex to implement.
6. Impact on Anti-Cheat and DRM: The ability to bypass SMM protections has direct implications for anti-cheat systems in video games and Digital Rights Management (DRM). As discussed in the Q&A, an SMM exploit could allow an attacker to run undetected code, giving them an unfair advantage or facilitating content piracy, highlighting the broad reach of such fundamental architectural flaws.

Key Takeaways

• An architectural flaw, dubbed "Sinkclose," exists in AMD processors, enabling a Ring0 to SMM privilege escalation.
• The T Close bit in the TSEG Mask MSR is not protected by the SMM Lock bit, allowing Ring0 modification to redirect SMM data accesses to MMIO.
• The exploitation leverages an integer overflow during the GDT loading process in SMM, causing the processor to read a fake GDT from attacker-controlled DRAM.
• The SPI controller is instrumental in setting up the MMIO conditions necessary to trigger the integer overflow.
• This vulnerability allows for persistent firmware modification, demonstrated by changing the boot splash logo, and can bypass anti-cheat systems and other low-level security mechanisms.
• Prompt firmware updates from vendors are critical for mitigation, and strict MSR access control by hypervisors or secure boot processes can offer additional layers of defense.

About the Speaker(s)

Enrique Nissim and Krzysztof Okupski are security researchers with a focus on low-level system vulnerabilities, particularly within System Management Mode (SMM). Their previous work includes publishing blogs and presentations on SMM security, with notable contributions such as identifying several CVEs in 2023. They have also developed and released tools designed for checking SMM misconfigurations and known issues, demonstrating a deep expertise in platform firmware security. Their presentation on "AMD Sinkclose" at DEF CON 32 underscores their continued commitment to uncovering and responsibly disclosing architectural flaws in critical hardware components.