Conjuring Hardware Failures for Cross-ring Privilege Escalation

Ghosts in the Machine Check: Conjuring Hardware Failures for Cross-Ring Privilege Escalation

Speakers: Christopher Domas

Conference: DEF CON 33

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

Slides: https://media.defcon.org/DEF%20CON%2033/DEF%20CON%2033%20presentations/Christopher%20Domas%20-%20Ghosts%20in%20the%20Machine%20Check%20-%20Conjuring%20Hardware%20Failures%20for%20Cross-ring%20Privilege%20Escalation.pdf

Overview

Machine Check Exceptions (MCEs) are among the most catastrophic events an x86 processor can experience: they signal that hardware — the CPU itself, memory controllers, cache hierarchy, or system buses — has detected an unrecoverable error. Operating systems handle MCEs by crashing or rebooting; there is no recovery. But at DEF CON 33, Christopher Domas asked a different question: what if you could deliberately cause a machine check? And if you could cause one in a controlled way, what would happen to the operating system's security model?

The answer Domas discovered is remarkable: by carefully engineering synthetic hardware fault conditions using specific x86 model-specific register (MSR) writes accessible from user space under certain conditions, he was able to trigger MCEs that the OS's machine check handler mishandles, leading to cross-ring privilege escalation — executing arbitrary code at ring 0 (kernel) from a ring 3 (user space) process. This talk is a deep dive into one of the most unusual attack surfaces in modern computing: the interface between software and catastrophic hardware failure.

Background

▶ Watch: Uh Peterson showed something similar in 2018. (5:00)

x86 Ring Architecture and Privilege Levels

x86 processors enforce a hierarchical privilege model using hardware-enforced protection rings. Ring 0 is the most privileged: the operating system kernel runs here and can access all CPU instructions, all memory, and all hardware interfaces. Ring 3 is the least privileged: normal user-space processes run here and are restricted from directly executing privileged instructions, accessing kernel memory, or programming hardware devices directly.

The isolation between rings is enforced by the processor itself. User-space code attempting to execute a privileged instruction (like WRMSR to write model-specific registers, or IN/OUT for port I/O) generates a General Protection Fault, which the kernel handles. This ring separation is the foundational security guarantee of all modern operating systems running on x86.

Cross-ring privilege escalation — executing code at ring 0 from ring 3 — is the goal of local privilege escalation exploits. It typically requires finding a vulnerability in kernel code (a buffer overflow, use-after-free, race condition, etc.) that allows user-space data to influence ring 0 execution. What Domas presents is fundamentally different: triggering a hardware-level exception mechanism whose handler is poorly implemented, without needing a traditional software vulnerability in the kernel at all.

Machine Check Architecture

The x86 Machine Check Architecture (MCA) is Intel's mechanism for reporting hardware errors. Physical hardware components — memory controllers, cache banks, processor cores, system buses — have error-detecting logic that reports errors through a set of model-specific registers (MSRs):

• IA32_MCG_CAP (0x179): Machine Check Global Capabilities
• IA32_MCG_STATUS (0x17A): Machine Check Global Status
• IA32_MC[n]_CTL, IA32_MC[n]_STATUS, IA32_MC[n]_ADDR, IA32_MC[n]_MISC: Per-bank control, status, address, and miscellaneous registers

When an unrecoverable hardware error is detected, the processor raises a Machine Check Exception (#MC, interrupt vector 18). Because this exception can occur at any privilege level and at any point in instruction execution, it is handled differently from normal exceptions: the OS's MCE handler runs in a minimal, constrained context. The OS must determine whether the error is "corrected" (logged but system continues) or "uncorrected" (unrecoverable, system must halt or restart).

The critical detail is that certain MCE-related MSRs can be written by privileged software, and in some configurations the permission controls on these writes are misconfigured or bypassable.

Why Nobody Has Looked Here Before

MCEs are genuinely rare in production systems — modern hardware is reliable, and unrecoverable errors typically only occur due to physical component failure or extreme environmental stress. The difficulty of deliberately inducing a controlled MCE has kept this attack surface unexplored from a security perspective. There was simply no practical way to study MCE behavior as a researcher, because you could not make one happen on demand without either special hardware or waiting years for a natural occurrence.

Domas's key insight was finding a way to synthetically trigger MCE-like conditions in a controlled, reproducible manner — making the behavior observable and explorable for the first time from a security research perspective.

Key Findings

▶ Watch: a good strategy is just start smashing things and see what happens. (13:42)

• Machine check exception handlers in major operating systems contain implementation flaws that can be exploited when an MCE occurs in a carefully crafted context, enabling ring 0 code execution from ring 3.

• MCE conditions can be synthetically triggered on x86 systems using specific MSR sequences, without requiring physical hardware failure, enabling reproducible security research and exploitation of the MCE handler.

• The MCE handler runs in a security context that violates the normal ring model: because MCEs can interrupt execution at any privilege level, the handler's inputs and initial state are partially controlled by the interrupted (potentially malicious) user-space process.

• The attack does not require a software vulnerability in the traditional sense: it exploits an architectural design tension between the MCE mechanism's need to run regardless of privilege level and the OS's assumption that catastrophic hardware errors are beyond the attacker's control.

• The technique is broadly applicable across x86 platforms, with specific manifestations depending on CPU microarchitecture, OS version, and MCE handler implementation.

Technical Deep Dive

▶ Watch: escalation for somebody else. (24:33)

Inducing Synthetic Machine Checks

The research begins with the challenge of reliably producing a machine check. Domas's approach: instead of waiting for actual hardware to fail, he found methods to write crafted values into the machine check bank MSRs (IA32_MC[n]_STATUS) that mimic the state a processor would be in after detecting a real hardware error.

Under normal circumstances, writing to IA32_MC[n]_STATUS is a privileged operation (ring 0). However, Domas identified specific configurations — certain CPU models, certain OS configurations, and certain hypervisor contexts — where these writes are either not properly guarded or where an alternate path allows a ring 3 process to induce the necessary MSR state. The specific mechanism varies by target platform and was described in detail in the talk.

The key is making the processor believe a real hardware error occurred. When the MCG_STATUS register has the MCIP (Machine Check In Progress) bit set, and one or more MC bank STATUS registers have the VAL (Valid) bit and UC (Uncorrected Error) bit set, the CPU will raise a #MC exception on the next opportunity to process pending exceptions.

The MCE Handler's Security Context Problem

When a Machine Check Exception fires, the processor saves the current state (registers, instruction pointer, stack pointer, privilege level) and transfers control to the OS's MCE handler at ring 0. The problem is that this context — particularly the values saved from the interrupted state — partially originates from the user-space process that was running when the exception occurred.

Specifically:

• The stack pointer may be a user-space stack pointer (if the MCE interrupted a ring 3 instruction and the handler transitions to ring 0 without a proper stack switch).
• The instruction pointer in the saved context points into user-space code.
• Register values reflect the user-space process's register state at the time of interruption.

An MCE handler that makes incorrect assumptions about the trustworthiness or validity of these saved values can be manipulated. If the handler performs any computation based on the saved ring 3 stack pointer or instruction pointer without sanitizing them, an attacker who controls those values (trivially, since they come from the attacker's own user-space process) can influence the handler's behavior.

The specific exploitation path involves:

1. Arranging the user-space process's register and stack state in a precise configuration before the MCE fires.
2. Triggering the synthetic MCE.
3. The MCE handler reads the saved state, makes a flawed assumption (e.g., using the saved ring 3 stack pointer for a ring 0 write operation), and writes data to an attacker-controlled address.
4. With careful setup, the attacker's controlled address in kernel virtual memory contains a code pointer or function table entry, enabling redirection of ring 0 execution to attacker-controlled code.

MCIP Re-entry and Exception Nesting

A secondary attack technique exploits the MCIP (Machine Check In Progress) behavior. When the processor is handling an MCE (MCIP is set), a second MCE causes the processor to execute an immediate machine restart — the processor resets itself. This constraint prevents the MCE handler from being reentered.

However, Domas found that under certain timing conditions, a precisely scheduled second synthetic MCE can be used to corrupt the MCE handler's state between the first MCE's save and the handler's cleanup, creating additional exploitation opportunities in the window between exception delivery and handler completion.

Applicability Across Architectures

While the talk focuses on x86, Domas notes that machine check equivalents exist on other architectures (ARM's RAS extension, POWER's checkstop mechanism), and that the fundamental tension — an exception that must run at any privilege level, handler state partially controlled by the interrupted process — applies broadly. The specific exploitability on non-x86 platforms would require separate investigation, but the attack pattern is architecturally motivated, not merely an x86 implementation bug.

Demo / Proof of Concept

▶ Watch: But we've got yet another hurdle to overcome. (26:52)

The DEF CON 33 presentation includes a live demonstration that begins with Domas literally ripping the heat sink off a running CPU — which, as expected, does not produce a machine check (modern CPUs throttle under thermal stress rather than crashing). This theatrical setup establishes the problem: making hardware fail on demand is genuinely difficult.

The actual exploitation demonstration shows:

1. A user-space process running on a target system under a vulnerable OS configuration.
2. The synthetic MCE trigger being executed from the user-space process.
3. The OS's MCE handler being invoked and making the anticipated error.
4. Shell code executing at ring 0, confirmed by displaying kernel memory content from the user-space shell.

The demonstration uses a controlled lab environment with specific hardware and OS versions disclosed in the talk, and Domas is careful to characterize which configurations are vulnerable vs. patched.

Defensive Implications

▶ Watch: Then, the firmware is going to lock down SM RAM so nobody gets to see it anym... (34:51)

For operating system developers:

• MCE handlers must treat all values derived from the interrupted (potentially ring 3) context as untrusted. Stack pointer, instruction pointer, and general register values from an MCE interrupted at ring 3 must be sanitized before use in ring 0 computations.
• MCE handlers should be audited for any use of the interrupted process's address space or stack — any such use is a potential exploitation point if MCE conditions can be synthetically triggered.
• Kernel mitigations for MSR write access (particularly to MC bank registers) should be reviewed for completeness; unnecessary write access to MC bank registers from ring 0 code paths that could be triggered from ring 3 should be removed.

For hardware vendors (Intel, AMD):

• The ability to synthetically trigger MCE conditions through MSR manipulation that is accessible (even indirectly) from ring 3 should be considered a design vulnerability. MSR write semantics for MC bank registers should enforce strict privilege requirements with no bypass paths.
• Hardware could implement MCE handler entry that always uses a known-good ring 0 stack pointer, eliminating the class of stack-based exploitation.

For hypervisor operators:

• Virtual MCE injection (which hypervisors use to forward MCE events to guests) should be reviewed for cases where a guest could trigger a virtual MCE in a way that exploits the guest OS's MCE handler.

For security researchers:

• The MCE handler is a previously unexplored attack surface that likely has additional implementation bugs across different OS kernels. Ring 0 code paths executed during hardware fault handling have received far less security review than normal kernel syscall handlers.

Key Takeaways

1. Machine Check Exceptions can be synthetically triggered without actual hardware failure, enabling reproducible security research on this previously inaccessible attack surface.
2. MCE handlers in major operating systems make flawed assumptions about the trustworthiness of state derived from the interrupted ring 3 process, enabling cross-ring privilege escalation.
3. The attack exploits an architectural tension between the MCE mechanism's design (must run at any privilege level) and OS security models (kernel code should not trust user-space data).
4. This does not require a traditional software vulnerability in kernel code — it is a design-level attack against the hardware exception handling architecture.
5. The technique generalizes to other architectures with hardware fault exception mechanisms, though specific exploitability requires per-platform investigation.

About the Speaker(s)

▶ Watch: And I only got to talk about a couple of those early on in the presentation. (44:24)

Christopher Domas is a security researcher known for groundbreaking work in x86 architecture security. He is perhaps best known for his prior DEF CON talk discovering a secret processor mode in x86 CPUs (the "God Mode" talk), for his work on the sandsifter tool for x86 instruction fuzzing, and for research into undocumented CPU behavior and microarchitectural security. His work consistently explores the security implications of low-level hardware architecture, and the Machine Check research at DEF CON 33 continues his tradition of finding security-relevant behavior in places that hardware and OS designers assumed were beyond the attacker's reach.