Title: BadRAM Description: No description Keywords: No keywords Text content: BadRAM BadRAM Breaching Processor Security via Rogue Memory Modules Read the paper Cite Watch a Demo @inproceedings{badramsp25, title = {{BadRAM}: Practical Memory Aliasing Attacks on Trusted Execution Environments}, author = {De Meulemeester, Jesse and Wilke, Luca and Oswald, David and Eisenbarth, Thomas and Verbauwhede, Ingrid and Van Bulck, Jo}, booktitle = {46th {IEEE} Symposium on Security and Privacy ({S\&P})}, month = May, year = 2025, } 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 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. Find aliases Two CPU addresses now map to the same DRAM location. Our practical tools find these aliases in minutes. 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 Who conducted this research? 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) Am I affected by this bug? 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. Does BadRAM need physical access; is this realistic? 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: 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. 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. What is AMD SEV and who uses this technology? 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. What about other technologies like Intel SGX and Arm CCA? 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 How can BadRAM be mitigated? 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. Should I update my system? 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. What is the impact of BadRAM; isn't the memory encrypted anyway? 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. How is this different from cold boot attacks? 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. How do I check my DRAM is locked? 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 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. What memory generations are affected? 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. Is this related to BadRAM feature in Linux? 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. What equipment do I need? 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 Where can I find more information? For more details, you can access the research paper and additional resources on our GitHub repository . Can I use the logo? The logo is free to use, rights waived via CC0. Logo (white background) SVG PNG Logo (transparent background) SVG PNG Is there a CVE identifier? CVE-2024-21944 is the identifier that is used to track BadRAM. It is also tracked by AMD under AMD-SB-3015. Is there source code to reproduce the attacks? Yes, our GitHub repository contains all scripts to modify the SPD chip, and proof-of-concept code for our attacks. Icons on this website are CC-BY-SA3 by the Noun project. This work was supported by the Research Fund KU Leuven, the Research Foundation – Flanders (FWO) via grant #1261222, and the Flemish Government (Cybersecurity Research Program) via grant VOEWICS02. In addition, this work is supported by the European Commission through Horizon 2020 (ERC #101020005 BELFORT), and Horizon Europe (#101070008 ORSHIN). This research was also partially funded by the Engineering and Physical Sciences Research Council (EPSRC) under grants EP/X03738X/1, EP/V000454/1, and EP/R012598/1. The results feed into DsbDtech. Additionally, this work was supported by the German BMBF project SASVI. Jesse De Meulemeester is funded by an FWO fellowship (11PFE24N).