https://arstechnica.com/information-technology/2024/12/new-badram-attack-neuters-security-assurances-in-amd-epyc-processors/ Skip to content Ars Technica home Sections Forum Subscribe * AI * Biz & IT * Cars * Culture * Gaming * Health * Policy * Science * Security * Space * Tech * Feature * Reviews * Store * AI * Biz & IT * Cars * Culture * Gaming * Health * Policy * Science * Security * Space * Tech Forum Subscribe Story text Size [Standard] Width * [Standard] Links [Standard] * Subscribers only Learn more Pin to story Theme * HyperLight * Day & Night * Dark * System Search dialog... Sign In Sign in dialog... Sign in BEWARE OF GHOSTS AMD's trusted execution environment blown wide open by new BadRAM attack Attack bypasses AMD protection promising security, even when a server is compromised. Dan Goodin - Dec 10, 2024 12:08 pm | 75 [cloud-computing-640x452] [cloud-computing-1000x648] Credit: Getty Images Credit: Getty Images Text settings Story text Size [Standard] Width * [Standard] Links [Standard] * Subscribers only Learn more Minimize to nav 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. [badram-hardware-spd-tamper] The researchers' Raspberry Pi connected to the SPD chip of a DIMM. Credit: De Meulemeester et al. 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 Lubeck, and the University of Birmingham. Specifically, they are: * Jesse De Meulemeester (COSIC, Department of Electrical Engineering, KU Leuven) * Luca Wilke (University of Lubeck) * David Oswald (University of Birmingham) * Thomas Eisenbarth (University of Lubeck) * 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." Photo of Dan Goodin Dan Goodin Senior Security Editor Dan Goodin Senior Security Editor Dan Goodin is Senior Security Editor at Ars Technica, where he oversees coverage of malware, computer espionage, botnets, hardware hacking, encryption, and passwords. In his spare time, he enjoys gardening, cooking, and following the independent music scene. Dan is based in San Francisco. Follow him at here on Mastodon and here on Bluesky. Contact him on Signal at DanArs.82. 75 Comments Staff Picks b breze Kind of tired of the panic over these attacks that will never happen in the wild because they are totally impractical or require unfettered physical access, at which point you are already done. The promise of cloud infrastructure is that they'll host things in an environment where the cloud provider has unfettered physical access, but they'll do it securely. These articles are good because they remind us that this is a complete lie. December 10, 2024 at 5:59 pm D Drum Kind of tired of the panic over these attacks that will never happen in the wild because they are totally impractical or require unfettered physical access, at which point you are already done. Isn't the second paragraph of the article: 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 reside 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. Regardless, these server attacks are pretty much never relevant for 90%+ of individuals, maybe even of businesses. They are relevant for anybody storing specific extremely highly sensitive data that people might be interested in stealing. December 10, 2024 at 6:02 pm O Old_Fogie_Late_Bloomer Talk about sensationalized headline. You need to have both physical access (or supply chain attack on vendor provided RAM), and physical access to the server to even make this possible with some form of login. At that point the "attack" is pretty meaningless with that level of access. You honestly think that this is beyond the reach of domestic intelligence agencies, especially ones already doing business with those cloud providers? For that matter, you honestly think this is beyond the reach of foreign intelligence agencies? Woof, I wish I lived in your world. December 10, 2024 at 6:26 pm xizive xizive This is not a threat against your grandmother's FaceBook page. It is a very real threat against specific high-value targets, such as Bitcoin brokers, where the payoff is more than enough to justify bribing a datacenter manager for some "alone time" with a server rack. December 10, 2024 at 6:27 pm a alansh42 People are missing the point. You can't boot into single user mode because the drive is encrypted and you can't mount the volume without the key. The RAM is encrypted to prevent a hypervisor from examining the memory within the VM. The CPU enforces this, but only in the RAM used for the VM. The flaw creates an aliased address outside the protected region that the hypervisor can read. December 10, 2024 at 6:53 pm Comments Forum view Loading Loading comments... Prev story Next story Most Read 1. Listing image for first story in Most Read: In a not-so-subtle signal to regulators, Blue Origin says New Glenn is ready 1. In a not-so-subtle signal to regulators, Blue Origin says New Glenn is ready 2. 2. Apple hit with $1.2B lawsuit after killing controversial CSAM-detecting tool 3. 3. Ten months after first tease, OpenAI launches Sora video generation publicly 4. 4. Efficiency, power, luxury: The 2025 Lucid Gravity SUV nails all three 5. 5. The iPhone accessories that let me ditch my laptop while traveling Customize Ars Technica has been separating the signal from the noise for over 25 years. With our unique combination of technical savvy and wide-ranging interest in the technological arts and sciences, Ars is the trusted source in a sea of information. After all, you don't need to know everything, only what's important. More from Ars * About Us * Staff Directory * Newsletters * Ars Videos * General FAQ * RSS Feeds Contact * Contact us * Advertise with us * Reprints Do Not Sell My Personal Information (c) 2024 Conde Nast. All rights reserved. Use of and/or registration on any portion of this site constitutes acceptance of our User Agreement and Privacy Policy and Cookie Statement and Ars Technica Addendum and Your California Privacy Rights. Ars Technica may earn compensation on sales from links on this site. Read our affiliate link policy. The material on this site may not be reproduced, distributed, transmitted, cached or otherwise used, except with the prior written permission of Conde Nast. Ad Choices