Posts Tagged ‘HardwareSecurity’
[DefCon32] AMDSinkclose – Universal Ring2 Privilege Escalation
In the intricate landscape of hardware security, vulnerabilities often lurk within architectural designs that have persisted for years. Enrique Nissim and Krzysztof Okupski, principal security consultants at IOActive, unravel a profound flaw in AMD processors, dubbed AMDSinkclose. Their exploration reveals how this issue enables attackers to escalate privileges to System Management Mode (SMM), granting unparalleled access to system resources. By dissecting the mechanics of SMM and the processor’s memory handling, they demonstrate exploitation paths that bypass traditional safeguards, affecting a vast array of devices from laptops to servers.
SMM represents one of the most potent execution environments in x86 architectures, offering unrestricted control over I/O devices and memory. It operates stealthily, invisible to operating systems, hypervisors, and security tools like antivirus or endpoint detection systems. During boot, firmware initializes hardware and loads SMM code into a protected memory region called SMRAM. At runtime, the OS can invoke SMM services for tasks such as power management or security checks via System Management Interrupts (SMIs). When an SMI triggers, the processor saves its state in SMRAM, executes the necessary operations, and resumes normal activity. This isolation makes SMM an attractive target for persistence mechanisms, including bootkits or firmware implants.
The duo’s prior research focused on vendor misconfigurations and software flaws in SMM components, yielding tools for vulnerability detection and several CVEs in 2023. However, AMDSinkclose shifts the lens to an inherent processor defect. Unlike Intel systems, where SMM-related Model-Specific Registers (MSRs) are accessible only within SMM, AMD allows ring-0 access to these registers. While an SMM lock bit prevents runtime tampering with key configurations, a critical oversight in the documentation exposes two fields—TClose and AClose—not covered by this lock. TClose, in particular, redirects data accesses in SMM to Memory-Mapped I/O (MMIO) instead of SMRAM, creating a pathway for manipulation.
Architectural Foundations and the Core Vulnerability
At the heart of SMM security lies the memory controller’s role in protecting SMRAM. Firmware configures registers like TSEG Base, TSEG Mask, and SMM Base to overlap and shield this region. The TSEG Mask includes fields for enabling protections, but the unlocked TClose bit allows ring-0 users to set it, altering behavior without violating the lock. When activated, instruction fetches in SMM remain directed to DRAM, but data accesses divert to MMIO. This split enables attackers to control execution by mapping malicious content into the MMIO space.
The feature originated around 2006 to allow SMM code to access I/O devices using SMRAM’s physical addresses, though no vendors appear to utilize it. Documentation warns against leaving TClose set upon SMM exit, as it could misdirect state saves to MMIO. Yet, from ring-0, setting this bit and triggering an SMI causes immediate system instability—freezes or hangs—due to erroneous data handling. This echoes the 2015 Memory Sinkhole attack by Christopher Domas, which remapped the APIC to overlap TSEG, but AMDSinkclose affects the entire TSEG region, amplifying the impact.
Brainstorming exploits, Enrique and Krzysztof considered remapping PCI devices to overlay SMRAM, but initial attempts failed due to hardware restrictions. Instead, they targeted the SMM entry point, a vendor-defined layout typically following EDK2 standards. This includes a core area for support code, per-core SMM bases with entry points at offset 0x8000, and save states at 0xFE00. By setting TClose and invoking an SMI, data reads from these offsets redirect to MMIO, allowing control if an attacker maps a suitable device there.
Exploitation Techniques and Multi-Core Challenges
Exploiting AMDSinkclose requires precise manipulation of the Global Descriptor Table (GDT) and Interrupt Descriptor Table (IDT) within SMM. Upon SMI entry, the processor operates in real mode, loading a GDT from the save state to transition to protected mode. By controlling data fetches via TClose, attackers can supply a malicious GDT, enabling arbitrary code execution. The challenge lies in aligning MMIO mappings with SMM offsets, as direct PCI remapping proved ineffective.
The solution involves leveraging the processor’s address wraparound behavior. In protected mode, addresses exceeding 4GB wrap around, but SMM’s real-mode entry point operates at a lower level where this wraparound can be exploited. By setting the SMM base to a high address like 0xFFFFFFF0, data accesses wrap to low MMIO regions (0x0 to 0xFFF), where integrated devices like the Local APIC reside. This allows overwriting the GDT with controlled content from the APIC’s registers.
Multi-core systems introduce complexity, as all cores enter SMM simultaneously during a broadcast SMI. The exploit must handle concurrent execution, ensuring only one core performs the malicious action while others halt safely. Disabling Simultaneous Multithreading (SMT) simplifies this, but wraparound enables targeting specific cores. Testing on Ryzen laptops confirmed reliability, with code injection succeeding across threads.
Impact on Firmware and Mitigation Strategies
The ramifications extend to firmware persistence. Once in SMM, attackers disable SPI flash protections like ROM Armor, enabling writes to non-volatile storage. Depending on configurations—such as Platform Secure Boot (PSB)—outcomes vary. Fully enabled protections limit writes to variables, potentially breaking Secure Boot by altering keys. Absent PSB, full firmware implants become feasible, resistant to OS reinstalls or updates, as malware can intercept and falsify flash operations.
Research on vendor configurations reveals widespread vulnerabilities: many systems lack ROM Armor or PSB, exposing them to implants. Even with protections, bootkits remain possible, executing pre-OS loader. A fused disable of PSB ensures perpetual vulnerability.
AMD’s microcode update addresses the issue, though coverage may vary. OEMs can patch SMM entry points to detect and halt on TClose activation, integrable into EDK2 or Coreboot. Users might trap MSR accesses via hypervisors. Reported in October 2023, CVE-2023-31315 was assigned, with an advisory published recently. Exploit code is forthcoming, underscoring the need for deepened architectural scrutiny.