Author name: Paul Patrick

One of the oldest maxims in hacking is that once an attacker has physical access to a device, it’s game over for its security. The basis is sound. It doesn’t matter how locked down a phone, computer, or other machine is; if someone intent on hacking it gains the ability to physically manipulate it, the chances of success are all but guaranteed.

In the age of cloud computing, this widely accepted principle is no longer universally true. Some of the world’s most sensitive information—health records, financial account information, sealed legal documents, and the like—now often resides on servers that receive day-to-day maintenance from unknown administrators working in cloud centers thousands of miles from the companies responsible for safeguarding it.

Bad (RAM) to the bone

In response, chipmakers have begun baking protections into their silicon to provide assurances that even if a server has been physically tampered with or infected with malware, sensitive data funneled through virtual machines can’t be accessed without an encryption key that’s known only to the VM administrator. Under this scenario, admins inside the cloud provider, law enforcement agencies with a court warrant, and hackers who manage to compromise the server are out of luck.

On Tuesday, an international team of researchers unveiled BadRAM, a proof-of-concept attack that completely undermines security assurances that chipmaker AMD makes to users of one of its most expensive and well-fortified microprocessor product lines. Starting with the AMD Epyc 7003 processor, a feature known as SEV-SNP—short for Secure Encrypted Virtualization and Secure Nested Paging—has provided the cryptographic means for certifying that a VM hasn’t been compromised by any sort of backdoor installed by someone with access to the physical machine running it.

If a VM has been backdoored, the cryptographic attestation will fail and immediately alert the VM admin of the compromise. Or at least that’s how SEV-SNP is designed to work. BadRAM is an attack that a server admin can carry out in minutes, using either about $10 of hardware, or in some cases, software only, to cause DDR4 or DDR5 memory modules to misreport during bootup the amount of memory capacity they have. From then on, SEV-SNP will be permanently made to suppress the cryptographic hash attesting its integrity even when the VM has been badly compromised.

“BadRAM completely undermines trust in AMD’s latest Secure Encrypted Virtualization (SEV-SNP) technology, which is widely deployed by major cloud providers, including Amazon AWS, Google Cloud, and Microsoft Azure,” members of the research team wrote in an email. “BadRAM for the first time studies the security risks of bad RAM—rogue memory modules that deliberately provide false information to the processor during startup. We show how BadRAM attackers can fake critical remote attestation reports and insert undetectable backdoors into _any_ SEV-protected VM.”

Compromising the AMD SEV ecosystem

On a website providing more information about the attack, the researchers wrote:

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.

In response to a vulnerability report filed by the researchers, AMD has already shipped patches to affected customers, a company spokesperson said. The researchers say there are no performance penalties, other than the possibility of additional time required during boot up. The BadRAM vulnerability is tracked in the industry as CVE-2024-21944 and AMD-SB-3015 by the chipmaker.

A stroll down memory lane

Modern dynamic random access memory for servers typically comes in the form of DIMMs, short for Dual In-Line Memory Modules. The basic building block of these rectangular sticks are capacitors, which, when charged, represent a binary 1 and, when discharged, represent a 0. The capacitors are organized into cells, which are organized into arrays of rows and columns, which are further arranged into ranks and banks. The more capacitors that are stuffed into a DIMM, the more capacity it has to store data. Servers usually have multiple DIMMs that are organized into channels that can be processed in parallel.

For a server to store or access a particular piece of data, it first must locate where the bits representing it are stored in this vast configuration of transistors. Locations are tracked through addresses that map the channel, rank, bank row, and column. For performance reasons, the task of translating these physical addresses to DRAM address bits—a job assigned to the memory controller—isn’t a one-to-one mapping. Rather, consecutive addresses are spread across different channels, ranks, and banks.

Before the server can map these locations, it must first know how many DIMMs are connected and the total capacity of memory they provide. This information is provided each time the server boots, when the BIOS queries the SPD—short for Serial Presence Detect—chip found on the surface of the DIMM. This chip is responsible for providing the BIOS basic information about available memory. BadRAM causes the SPD chip to report that its capacity is twice what it actually is. It does this by adding an extra addressing bit.

To do this, a server admin need only briefly connect a specially programmed Raspberry Pi to the SPD chip just once.

Hacking by numbers, 1, 2, 3

In some cases, with certain DIMM models that don’t adequately lock down the chip, the modification can likely be done through software. In either case, the modification need only occur once. From then on, the SPD chip will falsify the memory capacity available.

Next, the server admin configures the operating system to ignore the newly created “ghost memory,” meaning the top half of the capacity reported by the compromised SPD chip, but continue to map to the lower half of the real memory. On Linux, this configuration can be done with the `memmap` kernel command-line parameter. The researchers’ paper, titled BadRAM: Practical Memory Aliasing Attacks on Trusted Execution Environments, provides many more details about the attack.

Next, a script developed as part of BadRAM allows the attacker to quickly find the memory locations of ghost memory bits. These aliases give the attacker access to memory regions that SEV-SNP is supposed to make inaccessible. This allows the attacker to read and write to these protected memory regions.

Access to this normally fortified region of memory allows the attacker to copy the cryptographic hash SEV-SNP creates to attest to the integrity of the VM. The access also permits the attacker to boot an SEV-compliant VM that has been backdoored. Normally, this malicious VM would trigger a warning in the form of a cryptographic hash. BadRAM allows the attacker to replace this attestation failure hash with the attestation success hash collected earlier.

The primary steps involved in BadRAM attacks are:

1. Compromise the memory module to lie about its size and thus trick the CPU into accessing the nonexistent ghost addresses that have been silently mapped to existing memory regions.
2. Find aliases. These addresses map to the same DRAM location.
3. Bypass CPU Access Control. The aliases allow the attacker to bypass memory protections that are supposed to prevent the reading of and writing to regions storing sensitive data.

Beware of the ghost bit

For those looking for more technical details, Jesse De Meulemeester, who along with Luca Wilke was lead co-author of the paper, provided the following, which more casual readers can skip:

In our attack, there are two addresses that go to the same DRAM location; one is the original address, the other one is what we call the alias.

When we modify the SPD, we double its size. At a low level, this means all memory addresses now appear to have one extra bit. This extra bit is what we call the “ghost” bit, it is the address bit that is used by the CPU, but is not used (thus ignored) by the DIMM. The addresses for which this “ghost” bit is 0 are the original addresses, and the addresses for which this bit is 1 is the “ghost” memory.

This explains how we can access protected data like the launch digest. The launch digest is stored at an address with the ghost bit set to 0, and this address is protected; any attempt to access it is blocked by the CPU. However, if we try to access the same address with the ghost bit set to 1, the CPU treats it as a completely new address and allows access. On the DIMM side, the ghost bit is ignored, so both addresses (with ghost bit 0 or 1) point to the same physical memory location.

A small example to illustrate this:

Original SPD: 4 bit addresses:

CPU: address 1101 -> DIMM: address 1101

Modified SPD: Reports 5 bits even though it only has 4:

CPU: address 01101 -> DIMM: address 1101

CPU: address 11101 -> DIMM: address 1101

In this case 01101 is the protected address, 11101 is the alias. Even though to the CPU they seem like two different addresses, they go to the same DRAM location.

As noted earlier, some DIMM models don’t lock down the SPD chip, a failure that likely makes software-only modifications possible. Specifically, the researchers found that two DDR4 models made by Corsair contained this flaw.

In a statement, AMD officials wrote:

AMD believes exploiting the disclosed vulnerability requires an attacker either having physical access to the system, operating system kernel access on a system with unlocked memory modules, or installing a customized, malicious BIOS. AMD recommends utilizing memory modules that lock Serial Presence Detect (SPD), as well as following physical system security best practices. AMD has also released firmware updates to customers to mitigate the vulnerability.

Members of the research team are from KU Leuven, the University of Lübeck, and the University of Birmingham. Specifically, they are:

• 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)

The researchers tested BadRAM against the Intel SGX, a competing microprocessor sold by AMD’s much bigger rival promising integrity assurances comparable to SEV-SNP. The classic, now-discontinued version of the SGX did allow reading of protected regions, but not writing to them. The current Intel Scalable SGX and Intel TDX processors, however, allowed no reading or writing. Since a comparable Arm processor wasn’t available for testing, it’s unknown if it’s vulnerable.

Despite the lack of universality, the researchers warned that the design flaws underpinning the BadRAM vulnerability may creep into other systems and should always use the mitigations AMD has now put in place.

“Since our BadRAM primitive is generic, we argue that such countermeasures should be considered when designing a system against untrusted DRAM,” the researchers wrote in their paper. “While advanced hardware-level attacks could potentially circumvent the currently used countermeasures, further research is required to judge whether they can be carried out in an impactful attacker model.”