ZombieLoad Attack: Resurrecting Dead Data (Part 4)

Share:

The Dead Don’t Stay Dead

cpu side-channel exploit intel mds

The Dead Don’t Stay Dead

If Meltdown melted the fences between kernel and user space, and Spectre tricked the guard into letting us in, ZombieLoad is like rummaging through the guard’s trash bin before he has a chance to empty it.

Discovered in 2019, ZombieLoad (RIDL/Fallout) belongs to a class of vulnerabilities known as Microarchitectural Data Sampling (MDS). Unlike its predecessors which attacked the cache or branch predictor, ZombieLoad attacks the Buffers—the temporary holding grounds for data moving between the CPU caches and execution units.

In this article, we will dissect how your processor inadvertently resurrects “dead” data you thought was safe.

---

The concept: Fill Buffers

To understand ZombieLoad, we must look at a specific component: the Line Fill Buffer (LFB).

When a CPU core needs data, it asks the L1 Cache. If the L1 Cache doesn’t have it (a “cache miss”), the request goes to the L2/L3 cache or RAM. While waiting for that slow retrieval, the CPU doesn’t just sit idle. It stores the request in a Fill Buffer and continues executing other instructions speculatively.

Crucially, these buffers are shared resources within a Hyper-Threaded core.

The Attack: Sampling, Not Reading

The key distinction of MDS attacks is that the attacker cannot target a specific memory address like in Meltdown. They cannot say “Give me the password at address 0x1234”.

Instead, they can only sample whatever data happens to be passing through the buffers at that moment. It’s like listening to a crowded room; you can’t ask a specific person a question, but you can hear snippets of random conversations (passwords, keys, URLs) flying by.

Step-by-Step Execution

1. The Setup (Agitating the Zombie)

The attacker runs a malicious process on the same physical core as the victim (e.g., a browser or an encryption process). This is often achieved in cloud environments via Hyper-Threading.

2. The Fault

The attacker executes a memory load instruction that they know will fault (fail). For example, trying to load data that isn’t valid or requires a microcode assist.

// Concept code
char value = *invalid_address; // This will cause a fault

3. The Speculative Leak

Normally, the fault stops execution. But due to Speculative Execution, the CPU has already eagerly pulled data into its internal buffers to prepare for the load.

Here is the glitch: The CPU doesn’t check if the data in the buffer belongs to the attacker. It simply grabs whatever is currently in the Line Fill Buffer.

If the victim process (running on the sibling thread) just fetched a password from memory, that password is sitting in the Fill Buffer. The attacker’s speculative load picks up this “Zombie” data.

4. The Side Channel (Exfiltration)

Just like Spectre/Meltdown, the attacker uses the retrieved zombie value as an index to touch a specific part of the proper ‘probe array’ in memory.

// The classic Flush+Reload technique
access(probe_array[zombie_value * 4096]);

5. Recovery

The fault is handled (caught), but the side-effect remains. The attacker measures the access time of the probe array. The fast index reveals the zombie value.

---

Why is this terrifying?

1. Cross-Process & Cross-VM: Since fill buffers are shared by Hyper-Threads, a malicious VM in the cloud could read data from a legitimate VM running on the same physical core.
2. SGX Breach: Intel SGX (Software Guard Extensions) is designed to be a secure vault even if the OS is compromised. ZombieLoad can bypass the walls of this vault and read the secrets inside, rendering the “Secure Enclave” concept vulnerable.
3. Browser Exploits: JavaScript in a malicious tab could theoretically spy on your banking tab.

Mitigation: Flushing the World

The fix for ZombieLoad was heavy-handed because the flaw is architectural.

1. Microcode Updates: Intel released patches to overwrite buffers (VERW instruction) whenever switching between user/kernel transitions. This clears the trash bin, so there is no zombie data to resurrect.
2. Disabling Hyper-Threading: Many security-critical environments (like Google’s ChromeOS defaults at the time) recommended completely disabling Hyper-Threading, sacrificing up to 40% performance for security.

Conclusion

ZombieLoad taught us that data in flight is just as vulnerable as data at rest. It forced CPU architects to rethink how resources are shared between threads. In the next part, we will explore Rowhammer, where we stop reading memory and start breaking it.

Tharunaditya’s Security Note: Keep your BIOS/Firmware updated. These hardware patches are your primary defense against MDS attacks.

Discussion