DDRop: Cheap Hardware That Breaks Confidential Computing

DDRop: Cheap Hardware That Breaks Confidential Computing

Confidential computing's whole pitch is that the cloud can't touch your data. Intel TDX, AMD SEV-SNP and server-grade Intel SGX encrypt a virtual machine's memory so completely that even the hypervisor, the cloud provider, or someone standing in the data center sees only ciphertext. On 14 September researchers from KU Leuven, ETH Zurich, Durham University and Google showed that pitch has a hardware-sized hole in it (The Hacker News).

The attack is called DDRop, and the whole thing costs under $200 to pull off.

The promise and the missing freshness check

Confidential VMs encrypt memory with the processor's memory encryption engine: every line is plaintext only inside the CPU package, ciphertext on the bus and in the DIMMs. "Even someone with physical access to the machine sees only scrambled data," the researchers' writeup puts it.

But scalability forced a concession. To protect the terabytes of memory a cloud server holds, scalable memory encryption dropped a guarantee called freshness. The processor can confirm that memory is encrypted; it cannot confirm that memory holds the latest written value. Old encrypted data still decrypts perfectly — so if an attacker can make a fresh write vanish, the machine keeps chewing on stale values and decrypts them like nothing happened (The Register). Early client-side SGX had an integrity tree that caught exactly this; that protection was traded away on modern server platforms.

DDRop turns that blind spot into a weapon.

What the interposer actually does

DDRop is an active memory interposer: a small custom circuit board wired between the CPU socket and a DDR5 memory module. It sits on the memory bus, runs at full DDR5 speed — and silently drops write commands.

Normal:   CPU ──WRITE addr=0x7f0, value=NEW──▶ RAM   (NEW stored)
DDRop:    CPU ──WRITE addr=0x7f0, value=NEW──▶RAM ▸  × write discarded
                  │
                  └─ interposer forces an error on the command bus,
                     then cuts the wire the DIMM uses to report it
                     → the module silently drops the command
                     → CPU is never told, and later READs return the
                       OLD value, which still decrypts fine

To drop a write the board forces an error on the command bus, then severs the signal the memory module would use to report that error back. The module discards the command quietly; the CPU is none the wiser and later reads the previous value. Simple, and priced at about $159 in parts for one unit (The Hacker News).

What's genuinely new here is the price and the bus. Earlier passive DDR5 interposers (like TEE.fail) could only snoop, and needed lab gear to slow the bus down. The older active attacks that actually modified what memory saw — such as Battering RAM — were DDR4-only, because DDR5's redesigned command format blocks the address-swapping trick they used. DDRop is the first active interposer attack on DDR5, and it collapses the cost of the prior lab builds from an estimated $170,000 of equipment (The Register).

Breaking Intel TDX all the way to attestation

On TDX, dropped writes compound into full control of a protected VM. The trick is timing: when trusted firmware writes empty entries to initialize a page table, DDRop drops those writes — so the table instead keeps whatever attacker-chosen data was left in that memory region beforehand. An attacker's own VM can then map its memory onto any physical address and read or modify protected memory.

From there the researchers demonstrated a hat trick:

• Read a victim VM's private memory outright.
• Switch the victim into debug mode, copy its memory in plaintext, then restore the original data — the victim shows no sign of tampering.
• Overwrite the launch measurement a VM uses to prove to a remote customer that it booted into a known, trusted state. A VM the attacker controls now passes attestation checks as if it were trusted — meaning software that verified your confidential VM would certify a backdoored one instead.

Two of those results (reading victim memory and toggling debug mode) only work under TDX's default logical integrity mode — the stronger cryptographic integrity mode, where they'd touch data belonging to another VM, blocks them. But the researchers argue attestation forgery survives even cryptographic integrity, because that write happens inside the attacker's own VM under its own key, and the mode adds no freshness check to detect the reused old contents. They couldn't confirm it — their test system didn't support that mode.

AMD SEV-SNP: real, but narrower

On AMD SEV-SNP, DDRop's results are more limited: dropping writes during the platform's page-relocation feature let the researchers copy one victim page's contents into another. The debug-mode and attestation-forgery chains are Intel-TDX-specific.

The blast radius is still wide, because the root cause is shared. TDX, Scalable SGX and SEV-SNP all encrypt memory without the freshness check that DDRop exploits, so all three are affected. Intel's retired Client SGX (desktop/laptop chips) is safe because it uses a hardware integrity tree. NVIDIA's confidential-computing GPUs sit outside reach — their memory lives inside the chip package, where no interposer fits. Arm's CCA wasn't tested and may be affected.

Threat model: who is this for?

Before the panic, calibrate the attacker. DDRop needs someone who already controls the server's software and can get a brief window of physical access — the interposer is fitted in minutes and then driven entirely from software. The researchers name the obvious candidates: a rogue data-center employee, tampering somewhere in the supply chain, or hardware seized under legal compulsion. Cloud providers including AWS, Microsoft Azure and Google Cloud offer TDX/SEV-SNP-based confidential VMs to protect customer workloads, and this attack is aimed squarely at that deployment. But there is no evidence DDRop has been used outside a laboratory, and it does not demonstrate that any cloud service has been broken into (The Hacker News).

The vendor response nobody should cheer about

Intel acknowledged the disclosure and said the attack is out of scope for its cloud computing threat model — it won't assign a CVE, calling the research area "out of scope, but not out of mind." AMD likewise said the attack falls outside the published SEV/SNP threat model, and no mitigation is planned. Intel notes its optional cryptographic-integrity mode already blocks part of DDRop and says it is working on stronger memory-encryption designs; one proposal, cache-line versioning, would add a freshness check to the memory bus — but the researchers note it's unclear whether it would stop DDRop. There is no simple software or hardware patch: closing the gap means new memory-encryption hardware that provides both integrity and freshness (The Register).

What this means for Malaysian teams

This lands at a moment when Malaysia's data-center boom is accelerating — we wrote about the gigawatt-scale Johor data-center build-out in YTL-JLand and Malaysia's gigawatt data-center push — and confidential VMs are increasingly sold as the compliance answer for data residency and sovereignty. The sobering read of DDRop: hardware-backed trust is only as strong as the physical security of the machine, and "the machine is encrypted" was never the same thing as "the machine is fresh."

DDRop doesn't change what confidential computing is good for. It defends against software-level attackers — the malicious hypervisor, the compromised OS, the curious provider employee with root. What it does change is the claim that confidential computing alone survives a determined physical attacker. As we argued in AI sovereignty and the real cost of control, trust you actually control beats trust you're told to assume.

Practical mitigation, for now:

• Don't let one vendor's attestation be your only trust anchor — treat confidential VMs as defense-in-depth, not as a seal that rules out physical attackers.
• Watch the memory-management features DDRop abuses. Restricting the page-table and page-relocation paths, and checking that critical writes actually landed (read-back verification), raises the bar even if it can't remove the root cause.
• Take boot-time and supply-chain checks seriously. The researchers note software can look for an interposer at boot, and fitting one requires a physical window — physical security and hardware provenance are now part of the threat model, not optional.

DDRop is academic today and out-of-scope by declaration. It is also a reminder that "out of scope" is a threat-modeling choice, not a property of the hardware. If your confidential workload is the crown jewel, plan as if the machine itself is an adversary with a $159 budget.

Sources

• The Hacker News: New DDRop Attack Breaks Intel TDX and AMD SEV-SNP Confidential Computing
• The Register: New hardware device can RAM into encrypted memory, expose your data