Source: securityboulevard.com – Author: Chris Garland
Recent research has uncovered a concerning vulnerability in modern Trusted Execution Environments (TEEs) that challenges fundamental assumptions about memory security. The BadRAM attack, detailed in a paper by De Meulemeester et al., demonstrates how a low-cost hardware manipulation can compromise the integrity guarantees of systems like AMD SEV-SNP (Secure Encrypted Virtualization and Secure Nested Paging). Excitement surrounds new attack vectors, and the BadRAM research is certainly exciting, but it also builds upon similar attacks and research presented previously, such as:
- Eclypsium co-founder Alex Bazhaniuk and Eclypsium researcher Jesse Michael presented “Bricking or Implanting Servers: Not as Hard as You Think!” at Ekoparty 2018 and discussed SPD (Serial Presence Detect, more on that later) as a pathway to “bricking” a server and preventing it from booting. SPD alias attacks were also covered in public training given by the Eclypsium team at REcon Montreal and RingZer0 in 2019.
- Side channel-based attacks also allow reading from SPD, for example:
- The Forshadow attack was published in 2018 and represents research that allows attackers to extract sensitive data from Intel SGX-protected enclaves.
- The Downfall attack could also be used to circumvent Intel SGX.
- Intel SGX has a long history of attacks (see here, here, and here)
What is BadRAM?
BadRAM is a novel attack that creates aliases in the physical address space of DRAM modules. By manipulating the Serial Presence Detect (SPD) chip on a memory module, an attacker can trick the system into thinking the DRAM is larger than it actually is.
Note: Serial Presence Detect (SPD) is a critical feature in RAM modules that stores essential information about the memory’s specifications in an EEPROM chip, typically ranging from 128 to 1024 bytes. The SPD contains key parameters such as manufacturer data, memory capacity, speed ratings, and timing parameters, allowing the system’s BIOS to configure the memory for optimal performance automatically. Acting as a form of firmware for memory, SPD enables plug-and-play functionality, ensures standardization across manufacturers, and is accessible via the SMBus protocol. JEDEC standards are published and define the contents of the first 128-bytes of the SPD chip, which contain the required data for the DIMMs. There are a few spaces in the first 128-bytes for vendor-specific values, but some vendors use additional space past the 128-byte point for additional vendor-specific values. The presence of accurate SPD data is crucial for system stability and proper memory initialization, making it an indispensable component in modern computer systems.
This results in “ghost” addressing bits that create memory aliases – two different physical addresses that map to the same actual memory location. This aliasing allows an attacker to bypass access control restrictions imposed by SEV-SNP, potentially compromising confidentiality and integrity protections.
How Does it Work?
The attack exploits the Serial Presence Detect (SPD) chip found on memory modules (The protocol specifications date as far back as 1999). The SPD contains configuration data about the memory module that the BIOS reads during system initialization. By modifying this data, an attacker can cause the memory controller to use addressing bits that don’t actually exist on the physical DRAM.
The researchers developed a practical method to unlock and modify the SPD chip using a low-cost setup (around $10) based on a Raspberry Pi Pico microcontroller. This allows doubling the apparent size of the memory module by adding an extra addressing bit. It is important to note that this attack does not require physical access on systems that do not have SPD locked. In the advisory (https://badram.ue) the researchers explain the software-based attack scenario in more detail:
“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.”
The implications for TEEs are severe. For AMD SEV-SNP, BadRAM allows:
- Manipulation of memory mappings
- Corruption or replay of encrypted memory contents
- Compromise of the critical Reverse Map Table
- A devastating attack on the attestation feature that allows an attacker to run compromised VMs
For Intel SGX, while existing integrity protections prevent direct memory corruption, BadRAM enables the reading of memory regions in some implementations.
Detecting The Vulnerability – CVE-2024-21944
In response to the BadRAM research AMD published the security advisory titled “Undermining Integrity Features of SEV-SNP with Memory Aliasing (AMD-SB-3015)”. Carrying a CVSS score of 5.3 AMD described the vulnerability as “Improper input validation for DIMM serial presence detect (SPD) metadata could allow an attacker with physical access, ring0 access on a system with a non-compliant DIMM, or control over the Root of Trust for BIOS update, to potentially overwrite guest memory resulting in loss of guest data integrity.”
While AMD recommends using memory modules that lock SPD, they’ve also updated AGESA and SEV firmware versions to OEMs that address the issue.
Note: While the BadRAM research focused on AMD platforms, Intel platforms also address security issues surrounding SPD access. Intel implements SPD locking to protect memory module information from unauthorized modifications. This locking mechanism is typically enforced through BIOS settings and hardware-level protections, such as setting specific bits in the Platform Controller Hub (PCH)12. Intel platforms also have a write disable protection in the SMBus controller which prevents software from using the controller to perform write transactions to the external SPD EEPROM in the DIMM.
However, the System Management Mode (SMM), being the highest-privileged operating mode in x86 processors, can bypass these protections. Attackers who gain access to SMM could exploit vulnerabilities to modify SMM configuration, even when SMM Lock is enabled, potentially allowing arbitrary code execution and the ability to write to SPI flash, which could include altering SPD data.
A better defense is to use memory modules that themselves block write access to the SPD EEPROM contents even if the lock in the PCH is not set. AMD refers to this type of protection when recommending memory modules that lock the SPD. In this case, even if the SPD controller protection is unlocked or there’s a vulnerability in SMM that allows you to bypass that protection in the controller, if you’re using a DIMM that locks the SPD, the writes will be blocked even if the SPD controller in the chipset tries to perform writes. This type of write-locking of the SPD in the DIMM itself is more common in server memory, and it’s challenging to determine which memory modules are locked and which ones are not. There are also references to DIMMs with a physical switch that allows you to enable and disable writes to the SPD, but we haven’t seen one.
Updated firmware versions, specifically for AMD 3rd and 4th Gen EPYC processors, now include an ALIAS_CHECK intended to detect the presence of tampered memory mappings.
Lenovo has published an update for select systems to address CVE-2024-21944 in the December security update. The Eclypsium platform can detect the presence of this patch and alert if it has not been applied:
Checking for Locked SPD
To determine if your memory modules are potentially vulnerable to software-only BadRAM attacks, you can check if the SPD is properly write-protected using Linux utilities:
- For Linux systems, you can use the decode-dimms utility from the i2c-tools package. However, this utility may require that you load supporting kernel modules if they are not present already (e.g. sudo modprobe eeprom and sudo modprobe ee1004). Furthermore, the “eeprom” kernel driver was removed from the Linux kernel as of October 2023 and the replacement at24 driver doesn’t do the same level of device enumeration that decode-dimms depends on.
- Look for the “Write-protect” status in the output.
- Ideally, blocks 0 and 1 (containing critical configuration data) should be write-protected.
- For DDR4, the protection is indicated by WP0-WP3 flags. For DDR5, check the values of MR12 and MR13 registers.
Reference: DDR4 memory information in Linux
Linux kernel dependencies aside, not all memory modules support SPD locking, and the exact wording in the decode-dimms output may vary depending on the specific memory module and its capabilities. If you don’t see any explicit mention of write protection or locking in the output, your memory module doesn’t support this feature, or the information is unavailable through the SPD.
The Chipsec project also contains modules for checking SPD, in particular, you can check if the SPD lock is enabled or disabled using the following command:
$ sudo ./chipsec_main.py -m common.spd_wd
The results will look as follows, in this case, the SPD has been locked:
Also, even if SPD is locked, an attacker with physical access can unlock it. However, locked SPD raises the bar for attacks significantly.
Mitigation and Future Directions
The researchers responsibly disclosed their findings to AMD, who has released the aforementioned firmware updates. Intel’s newer TEE implementations (Scalable SGX and TDX) already include similar checks. Long-term solutions may involve rethinking trust assumptions about DRAM in TEE designs or implementing more robust cryptographic protections that can scale to large memory sizes.
The BadRAM attack serves as a stark reminder that even well-established security boundaries can be vulnerable to creative, low-cost attacks. As cloud computing and TEEs become increasingly prevalent, ensuring the integrity of memory subsystems will be crucial for maintaining trust in these technologies.
References & Resources
- AMD’s trusted execution environment blown wide open by new BadRAM attack
- BadRAM: Practical Memory Aliasing Attacks on Trusted Execution Environments (Paper)
- BadRAM: Breaching Processor Security via Rogue Memory Modules (Website with Demo
The post BadRAM-ifications: A Low-Cost Attack on Trusted Execution Environments appeared first on Eclypsium | Supply Chain Security for the Modern Enterprise.
*** This is a Security Bloggers Network syndicated blog from Eclypsium | Supply Chain Security for the Modern Enterprise authored by Chris Garland. Read the original post at: https://eclypsium.com/blog/amd-badram/
Original Post URL: https://securityboulevard.com/2024/12/badram-ifications-a-low-cost-attack-on-trusted-execution-environments/
Category & Tags: Security Bloggers Network,Blog – Security Bloggers Network,Blog
Views: 2