Rogue Memory: A Hidden Security Threat

Computers rely on a processor to perform calculations and memory (DRAM) to store code and data. Adding more memory can boost performance, with different tasks demanding varying amounts. When a computer starts up, it communicates with the connected DRAM modules to learn their size, speed, and configuration. But what if the DRAM module can be tricked into lying to the processor?

For the first time, we have studied the security risks of “bad RAM” — rogue memory modules that deliberately provide false information to the processor during startup. Our findings reveal a surprising and previously underexplored weakness in modern processor security technologies.

A $10 Hack That Erodes Trust in the Cloud

Modern computers increasingly use encryption to protect sensitive data in DRAM, especially in shared cloud environments with pervasive data breaches and insider threats. AMD's Secure Encrypted Virtualization (SEV) is a cutting-edge technology that protects privacy and trust in cloud computing by encrypting a virtual machine's (VM's) memory and isolating it from advanced attackers, even those compromising critical infrastructure like the virtual machine manager or firmware.

We found that tampering with the embedded SPD chip on commercial DRAM modules allows attackers to bypass SEV protections — including AMD’s latest SEV-SNP version. For less than $10 in off-the-shelf equipment, we can trick the processor into allowing access to encrypted memory. We build on this BadRAM attack primitive to completely compromise the AMD SEV ecosystem, faking remote attestation reports and inserting backdoors into any SEV-protected VM.

To mitigate the BadRAM vulnerability, AMD has issued firmware updates to securely validate memory configurations during the processor’s boot process.

BadRAM in 3 Simple Steps

1. Compromise the memory module

   BadRAM makes the memory module intentionally lie about its size, tricking the CPU into accessing nonexistent "ghost" addresses that are silently mapped to existing memory regions.

2. Find aliases

   Two CPU addresses now map to the same DRAM location. Our practical tools find these aliases in minutes.

3. Bypass CPU Access Control

   Through these aliases, attackers can bypass CPU memory protections, exposing sensitive data or causing disruptions.

BadRAM in Action

Attack 1/2: Simple Replay

In this attack demo we show how an attacker uses the BadRAM primitive to capture the content of a memory location of an SEV-SNP VM and replay it later on. This forms the building block for more advanced attacks.

Attack 2/2: Breaking SEV-SNP Attestation

The attestation report is a cryptographic measurement of a confidential VM that proves to the remote owner that their VM is protected correctly and has not been tampered with. Using the BadRAM attack, we can capture and replay the expected attestation measurement of a correct VM, making any malicious changes, such as inserting a completely invisible and undetectable backdoor into the remote VM owner. This effectively breaks all trust in the SEV-SNP ecosystem.

Questions and Answers

The research was conducted by researchers from KU Leuven, the University of Lübeck, and the University of Birmingham.

• Jesse De Meulemeester (COSIC, Department of Electrical Engineering, KU Leuven)
• Luca Wilke (University of Lübeck)
• David Oswald (University of Birmingham)
• Thomas Eisenbarth (University of Lübeck)
• Ingrid Verbauwhede (COSIC, Department of Electrical Engineering, KU Leuven)
• Jo Van Bulck (DistriNet, Department of Computer Science, KU Leuven)

While BadRAM may be possible on your system, it is primarily relevant in a cloud scenario with TEEs, where you inherently may not trust the cloud providers owning the systems. However, even in that scenario, there is no need to worry since we worked together with AMD to ensure appropriate countermeasures were developed that allow trusted firmware to detect BadRAM at boot time. Cloud providers will apply these updates to ensure your data remains secure.

BadRAM attacks require access to the SPD chip on the DIMM to modify its contents. This SPD chip can be exposed in several scenario's:

1. Insider Threats in Cloud Environments

   In a cloud environment, employees of the cloud provider or local law enforcement could gain physical access to the hardware. These insiders could trivially modify the SPD chip to enable BadRAM attacks.

2. Software-Based Attacks

   Some DRAM manufacturers fail to properly lock the SPD chip, leaving it vulnerable to modification by operating-system software after boot. This has previously already caused several cases of accidental SPD corruption. Additionally, some manufacturers intentionally leave SPD unlocked in the BIOS to support features like RGB lighting for gaming setups. If SPD is not securely locked, attackers with root privileges could launch BadRAM attacks entirely through software, without physical access. Furthermore, since memory initialization is handled by the BIOS, a compromised BIOS could also enable BadRAM exploits.

AMD Secure Encrypted Virtualization (SEV) is a hardware-based trusted execution environment designed to enable secure cloud computing without needing to trust the cloud provider or local law enforcement. AMD SEV protects data in use by implementing strong access controls within the CPU and encrypting all data before storing it in untrusted off-chip DRAM. AMD SEV encrypts memory with a dedicated key unique to each virtual machine, ensuring data privacy even if the host system is compromised. This technology has evolved through several iterations, with the latest being SEV-SNP, designed to offer advanced protection against page-remapping attacks from an untrusted hypervisor.

AMD SEV is widely used in cloud computing to enhance security and privacy, with major cloud providers like Amazon AWS, Google Cloud, Microsoft Azure, and IBM cloud offering this technology to protect their customers' data.

We found that other popular cloud TEEs, Intel TDX and scalable Intel SGX , include dedicated countermeasures against BadRAM aliasing attacks. At boot time, a trusted firmware module checks the protected memory range for aliases, and additional DRAM metadata tracks the protection status of each memory address. Thanks to these protections, we were unable to exploit BadRAM on these TEEs.

The older desktop version of SGX, now discontinued, is partially vulnerable to BadRAM. Compared to scalable SGX and TDX, this "classic" SGX featured much stronger memory encryption, including cryptographic freshness guarantees. However, this came at the cost of a limited protected memory size, prompting the industry to shift towards weaker, but more scalable, static memory encryption technologies. Using BadRAM, we observed changes in the encrypted, protected memory space, partially replicating a previous attack on classic SGX, dubbed MemBuster. While MemBuster originally required ~$170,000 and was only demonstrated on DDR4, we achieved it for less than $10 on both DDR4 and DDR5.

Arm has also announced a cloud TEE called CCA . Based on the specification, it appears that alias checking countermeasures are required. However, since no hardware is available yet, we were unable to test BadRAM on CCA.

The table below summarizes our findings across different TEEs. Each column indicates whether we were able to read, write, or replay ciphertexts in protected memory regions.

TEE	Read	Write	Replay
AMD SEV-SNP
Intel Classic SGX
Intel Scalable SGX
Intel TDX
Arm CCA

BadRAM can be mitigated by considering the SPD data as untrusted and performing memory alias checking at boot time, as seen in Intel's Alias Checking Trusted Module for TDX and scalable SGX. The countermeasures introduced by AMD will similarly validate SPD metadata during the boot process in trusted firmware.

Alternatively, strong cryptographic memory encryption that provides additional integrity and freshness guarantees, as employed in "classic" Intel SGX, almost entirely mitigates the security risks posed by BadRAM’s memory aliasing technique.

While it is good practice to keep your system up-to-date, there’s no immediate need for individual users to update their systems. At this time, most cloud providers will have updated their firmware to include the countermeasures provided by AMD.

BadRAM can circumvent critical CPU-based memory isolation features based on physical address checks, which has significant consequences for TEEs like AMD SEV-SNP.

While TEEs commonly encrypt data in memory, this encryption is static, meaning that the same plaintext always maps to the same ciphertext. This can prevent threats like cold boot attacks, but is not a significant roadblock for BadRAM. BadRAM can do more than just observe encrypted data—it can corrupt or replay ciphertexts. Since encryption is static, the replayed data decrypts to the same value, effectively allowing stale data to be used.

Even more concerning, we discovered that the critical Reverse Map Table (RMP) in AMD’s latest SEV-SNP architecture, designed specifically to protect against "SEVered" page-remapping attacks, is left unencrypted. With the RMP unencrypted, BadRAM can directly modify the memory mappings, completely bypassing the protections SEV-SNP was built to prevent. This allows attackers to arbitrarily swap memory mappings and enable arbitrary code execution and decryption of SEV-SNP virtual-machine memory.

Cold boot attacks exploit the residual data in DRAM by quickly restarting or transferring memory modules to extract secret data. These attacks can nowadays easily be mitigated by enabling full memory encryption, whereas this is not a big hurdle for BadRAM. BadRAM is also a more powerful attack, it is not only able to observe the memory at any given point, but can also actively modify or replay data.

On a Linux desktop or laptop equipped with DDR4 memory, you can easily verify if your DIMMs are locked from software access. To do this, use i2cdetect from the I2C tools to identify which I2C bus corresponds to the SMBus:

sudo i2cdetect -l

Once you have identified the correct bus number for the SMBus, you can scan it using:

sudo i2cdetect -y <number>

On the SMBus, you should see some I2C devices at addresses 0x50 through 0x58. These are the SPD chips associated with your DIMMs. If no devices appear within this range, it may indicate that your DRAM is soldered or that the SPDs are not directly accessible from the SMBus.

If no devices are detected at addresses 0x31 and 0x34, it means the SPDs are correctly locked. However, if devices are visible at these addresses, your DIMMs are not protected.

In our paper, we show that BadRAM affects DDR4 and DDR5. These generations both have unlockable SPD chips, making it easy to overwrite its contents. For older generations, like DDR3, that allow permanent write protection to the SPD, we show how BadRAM attacks are still possible by removing or swapping the SPD.

For the upcoming DDR6, specifications have not been released yet. However, it would be safe to assume they will also contain some kind of SPD device on the DIMM. As long as an attacker can modify the contents of this SPD, BadRAM might still be possible.

No, this paper is not related to the BadRAM feature that can be found in Linux and other operating systems. In that context, BadRAM is used to specify and filter out defective DRAM regions, which can be detected by tools such as Memtest86+. This feature can, however, be used to filter out the "ghost" memory regions created by BadRAM modules.

The SPD chip can be easily modified using a low-cost, off-the-shelf microcontroller. We used a Raspberry Pi Pico, for a total cost of around $10. Below is a bill of materials and an image of our Raspberry Pi Pico setup to unlock and modify DDR4 and DDR5 SPDs.

Component	Cost	Link
Raspberry Pi Pico	$5	Link
DDR Socket	$1-5	DDR4: [1], [2] DDR5: [1], [2]
9V source	$2	9V battery / Boost converter

For more details, you can access the research paper and additional resources on our GitHub repository .

The logo is free to use, rights waived via CC0.

Logo (white background)	SVG	PNG
Logo (transparent background)	SVG	PNG

CVE-2024-21944 is the identifier that is used to track BadRAM. It is also tracked by AMD under AMD-SB-3015.

Yes, our GitHub repository contains all scripts to modify the SPD chip, and proof-of-concept code for our attacks.