RAMming Down Hype via Intel CSME

Recently, security researchers found new vectors of exploiting a vulnerability in Intel CSME, CVE-2019-0090, affecting all Intel chips other than Generation 10 (Ice Lake). The researchers haven’t released exploitation details yet, but proclaimed that “utter chaos will reign”… but not by exploiting this vulnerability! Instead, there’s a potential for chaos if attackers figure out how to exploit secure storage (which these researchers didn’t) and leverage the same whisper of time — in which protection mechanisms aren’t loaded — that enables the disclosed attack.

With a statement so clearly designed to incite panic, the elder Panic Button gods told us it would be sacrilegious not to cover this vuln, so here we are.

Why the freak out? This vulnerability is “unfixable,” because it’s in hardware that is unchangeable by design once deployed. Most of its hype-worthy potential impact — shattering Intel’s root of trust on systems using any of the affected chips — is based on the assumption that attackers will figure out how to leverage a tiny window where this root of trust is unguarded from external devices. Specifically, the assumption is that attackers will figure out how to compromise the Secure Key Storage (SKS) in which the hardware encryption key — the key that validates system firmware and protects against tampering — resides.

Wait, backup! What’s “root of trust”? A root of trust is a trusted source that can validate that a system’s firmware is operating as intended and hasn’t been tampered. It’s usually implemented as a hardened hardware module that checks the cryptographic signatures of firmware before the system boots up. By design, a root of trust can’t be modified or updated, otherwise it’d be much easier for attackers to seize control of the validation chain for themselves (see this talk from 2012 for examples). 

In Intel chips, the Converged Security and Management Engine (CSME) is the subsystem which loads and verifies firmware. It has its own firmware and isolated execution environment, allowing it to perform secure boot, trusted execution of security services, overclocking, and more. We recommend perusing the slides from two Intel security researchers at Black Hat 2019 if you want a deeper dive into the CSME.

Importantly for understanding the “utter chaos” vuln in question, the CSME is the gatekeeper of static RAM (SRAM), where encryption keys and other system treasure is stored. To ensure external or internal devices can’t directly reach this prized SRAM (though the range of devices which can access SRAM vs. main memory is limited, as we’ll see), the CSME uses the input-output memory management unit (IOMMU) to control direct memory access (DMA).

Got it, so how does this attack work? When you turn on the system, the CSME’s ROM is the first thing to start. To oversimplify, ROM basically says, “Good morning, I’m going to generate an encryption key and the map of my memory addresses, and stick both over here in the SRAM box so no one else can touch them.” Then, the ROM Boot Extension (RBE) says, “Greetings, I am going to load and execute the CSME operating system.” Then, the micro kernel (aka uKernel) starts performing enforcement of code execution and process isolation — and, of most relevance for this vulnerability, drives the IOMMU.

As you can see, there’s a brief window of time where the encryption key and memory goodies are sitting in SRAM, but the uKernel is still making its coffee — meaning anti-DMA attack protections aren’t in place. Therefore, an attacker could wait for or trigger the ROM to say “good morning!”, perform code execution in the Integrated Sensor Hub (ISH), and then gain access to the data structure that controls the firmware validation process. This would grant the attacker arbitrary code execution at basically the lowest level of system operation (i.e. escalating privileges to Ring -2).

The researchers also note that many of the IOMMU mechanisms within the CSME are disabled by default. If these mechanisms of controlling access to SRAM aren’t flipped on, this means you’re not getting protection from DMA attacks — which leaves the CSME open to tampering via a side channel (i.e. a malicious external device connected to the system).

Yes, but: Arbitrary code execution is bad! But exploiting this vulnerability requires local access at a minimum,  compounded by the attacker needing to exploit a relevant device to gain a foothold on the system. This list of valid footholds is quite limited. For instance, an attacker would need to perform code execution in the ISH or other Platform Controller Hub (PCH) devices — exploiting PCIe devices (like GPUs or RAID controllers) wouldn’t suffice. Additionally, per the original blog post, other methods of exploitation require physical access. Either way, this is limited to incredibly motivated and well-resourced attackers (like a nation-state with a high-value target identified).

For real, though: The headlines and hype are primarily driven by the speculative part of the researcher’s blog post: that an attacker could use that same window of time, when the uKernel is making coffee and not stopping direct memory access, to extract the hardware key that drives the cryptographic system of the machine. 

The reason why they are all Book of Revelation about it is that there’s a single hardware key for each of Intel’s chipset generations. This means an attacker possessing the key could decrypt encrypted data, spoof hardware, and annihilate DRM (on any system using that generation of Intel chips). Consumer techies raging against DRM would rejoice, while enterprises relying on trusted computing would panic — perchance a dichotomy heralding the end times.

With that said: This highlights the risk created when a vendor builds opaque technology — the user is rendered to be at the vendor’s mercy, which risks systems security in cases like this. It is, perhaps, worth wondering whether enterprises and users should be reliant on a root of trust that is based on blackboxes, regardless of whether there are known vulnerabilities in its components. 

The bottom line: This disclosure itself demonstrates a new evil maid attack for Intel chipsets. It requires a supremely motivated and resourced attacker with at least (extremely non-trivially obtained) local access — if not physical access — which considerably reduces the probability of widespread exploitation. The speculation on a hypothetical decimation of Intel’s root of trust is a cute way to generate headlines — and there’s plausibly a nation state who’s already done it — but this isn’t the sequel to Heartbleed. 

However, there are real risks arising from the use of blackbox tech, and enterprises should be conscious of assuming an opaque root of trust is always patchable, let alone “unhackable.” Enterprises using Intel’s Management Engine to power full disk encryption should consider it potentially compromisable in their threat models, even though the likelihood of non-targeted exploitation is low.

Update: This post has been updated based on feedback from generous hardware security experts. Many thanks to Trammell Hudson (@qrs), Director of Special Projects at Lower Layer Labs, for his insight into how PCH devices are required to DMA into SRAM (not PCIe as we originally surmised). Additional thanks to Jeremiah Cox (@int0x6) for the great suggestion of disabling busmastering on PCI bridges as a method of raising attacker cost (though, as per Trammell’s insight, PCI bus devices wouldn’t be a valid foothold for DMA into SRAM anyway).

The Capsule8 Labs team conducts offensive and defensive research to understand the threat landscape for modern infrastructure and to continuously improve Capsule8’s attack coverage.