Beyond Cryptography: The New Reality of Microarchitectural Exploitation

TLDR: Modern CPU security is no longer just about side-channel attacks on cryptographic keys. Research presented at Black Hat 2024 demonstrates that transient execution and fault injection techniques are now being used to compromise general-purpose system security, including kernel address space layout and trusted execution environments. Pentesters must shift their focus from simple timing attacks to understanding how hardware-level optimizations like speculative execution and branch prediction can be manipulated to leak arbitrary data.

Hardware security has long been treated as a theoretical playground for academics, but the gap between research and practical exploitation has effectively vanished. For years, we focused on side channels as a way to extract RSA or AES keys. If you could measure the time it took for a CPU to perform a modular exponentiation, you could eventually reconstruct the private key. That was the era of "side channels as a cryptographic problem." The research presented at Black Hat 2024 makes it clear that we have entered a new phase where microarchitectural vulnerabilities are being used to break fundamental system security primitives.

The Shift to General-Purpose Exploitation

We are seeing a clear trend: researchers are moving away from targeting specific cryptographic implementations and toward attacking the operating system and trusted execution environments (TEEs) directly. When you look at the evolution of these attacks, the goal is no longer just to steal a key. It is to bypass kernel address space layout randomization (KASLR) or to extract secrets from an Intel SGX enclave.

Consider the KASLR bypass techniques that rely on prefetch side channels. By manipulating the CPU's prefetcher, an attacker can determine whether a specific memory address is cached. If it is, the attacker knows that the address is mapped, effectively leaking the kernel's memory layout. This is not a cryptographic attack. It is a system-level exploit that turns a hardware optimization into a primitive for further, more traditional software exploitation.

Transient Execution: When the CPU Lies to Itself

The most significant shift in the last few years is the move toward transient execution attacks. These are not traditional side channels where you observe a leakage over time. Instead, they are attacks where the CPU executes instructions that it should never have reached, leaving behind traces in the microarchitectural state before the processor realizes its mistake and rolls back the architectural changes.

The Spectre and Meltdown vulnerabilities fundamentally changed our understanding of the CPU pipeline. The core issue is that the CPU's "out-of-order" execution engine is too eager. It will speculatively execute instructions based on branch predictions, and if those predictions are wrong, the CPU discards the results. However, the side effects of those instructions—such as loading data into the cache—remain.

For a pentester, this means that your threat model must account for the fact that the CPU might execute code that violates your security boundaries. If you are testing an application that runs in a shared environment, you have to assume that the underlying hardware might be leaking data across those boundaries through the cache.

Fault Injection and the Physical Domain

Another area of concern is the rise of software-based fault injection. We used to think that fault injection required physical access—glitching the voltage or the clock signal with specialized hardware. That is no longer the case. Attacks like Platypus and VoltPillager demonstrate that you can manipulate the voltage of a processor directly from software, provided you have the right privileges.

By undervolting the CPU, you can induce faults in the computation. If you are targeting a cryptographic operation, these faults can be used to perform differential fault analysis, which is a devastatingly effective way to recover keys. The real-world risk here is that these attacks can be performed remotely if the attacker has already gained sufficient privileges on the target system.

What This Means for Your Next Engagement

If you are performing a penetration test on a system that relies on hardware-based security, you need to start asking harder questions. Are you testing the TEE? Are you looking for ways to influence the CPU's branch predictor? The days of ignoring the hardware layer are over.

Defenders are fighting back, but the mitigations are often as complex as the attacks. Features like Intel's Linear Address Space Separation (LASS) are designed to prevent these kinds of leaks, but they come with performance costs and implementation challenges. As a researcher, you should be looking for ways to bypass these mitigations. If a vendor claims that a specific microarchitectural feature is "secure," that is usually just an invitation to find the next side channel.

Microarchitecture is no longer a "black box" that we can safely ignore. It is a complex, stateful machine that is constantly making decisions about what to execute next. Every one of those decisions is a potential leak. The next time you are looking for a way to escalate privileges or bypass a sandbox, don't just look at the software. Look at the CPU. The hardware is not just the foundation of your security; it is often the most interesting part of the attack surface.