{"id":52849,"date":"2025-01-10T13:10:42","date_gmt":"2025-01-10T18:10:42","guid":{"rendered":"https:\/\/www.kaspersky.com\/blog\/?p=52849"},"modified":"2025-01-10T13:10:42","modified_gmt":"2025-01-10T18:10:42","slug":"badram-cpu-attack","status":"publish","type":"post","link":"https:\/\/www.kaspersky.com\/blog\/badram-cpu-attack\/52849\/","title":{"rendered":"BadRAM: an attack using a malicious RAM module"},"content":{"rendered":"

Researchers from three European universities recently demonstrated<\/a> the so-called BadRAM attack. This attack is made possible because of a vulnerability in AMD EPYC processors, and primarily threatens cloud-solution providers and virtualization systems. In the worst-case scenario, the vulnerability could be used to compromise data from highly secure virtual machines.<\/p>\n

However, implementing this scenario in practice would be quite difficult. The attack requires physical access to the server, plus the highest level of access to the software. Before discussing the BadRAM attack in detail, we should first understand the concept of a trusted execution environment (TEE).<\/p>\n

Features of TEE<\/h2>\n

Software errors are inevitable. Estimates from as early as the 1990s suggest that there are between one and 20 errors for every thousand lines of code. Some of these errors lead to vulnerabilities that malicious actors can exploit to access confidential information. Therefore, when certain data or computational processes (for example, processing private encryption keys) must be highly secure, it makes sense to isolate this data \u2014 or these processes \u2014 from the rest of the code. This is the essence of the trusted execution environment<\/a> concept.<\/p>\n

There are numerous TEE implementations designed for various tasks, each varying in the degree of security they provide. In AMD processors, TEE is implemented as Secure Encrypted Virtualization<\/a> (SEV) \u2014 a technology that enhances the protection of virtual machines. It encrypts the data of a virtual system in memory so that other virtual systems \u2014 or even the operators of the physical server running these virtual OSs \u2014 can\u2019t access it. Secure Nested Paging, a more recent extension of this technology, can detect unauthorized attempts to access virtual system data.<\/p>\n

Consider the scenario where a financial institution uses third-party infrastructure to run its virtual systems. These virtual OSs process highly confidential data, and it\u2019s essential to ensure their absolute security. While it\u2019s possible to impose stringent requirements on the provider of the infrastructure, in some cases it\u2019s easier to operate under the assumption that they can\u2019t be fully trusted.<\/p>\n

Secure Encrypted Virtualization, just like Intel\u2019s similar Trusted Domain Extensions (TDX) technology, essentially uses a separate processor. Although it\u2019s physically part of the server processor (Intel or AMD), it\u2019s effectively isolated from the main processor cores. By participating in the data encryption process, this isolated module provides an additional layer of security.<\/p>\n

Details of the BadRAM attack<\/h2>\n

Let\u2019s return to the BadRAM attack. It bypasses the Secure Encrypted Virtualization protection and gains access to the encrypted data of a virtual system in such a way that the Secure Nested Paging technology is also unable to detect the breach. This video<\/a> shows how a \u201cmalicious\u201d application on a server can read data from a protected virtual machine running on the same server.<\/p>\n

How does it work? The authors of the study used a very unusual attack method \u2014 modifying the hardware itself. Every computer has random access memory (RAM). Each memory module contains several chips for storing data, plus one service chip \u2014 known as the SPD<\/a>. This chip announces the presence of the memory module in the system and transmits key parameters (such as the optimal operating frequency of the memory chips and their capacity) to the processor. It was precisely this information about the capacity that the researchers modified.<\/p>\n

This is a rather paradoxical attack method. First, the attackers take a 32GB memory module; then, they re-flash the SPD chip, setting its capacity to twice that amount \u2014 64GB. The processor trusts this information and tries to use the memory module as if its capacity was indeed 64GB. Under normal circumstances, this would quickly lead to freezes or other failures: some data blocks would simply overwrite others, and information from various applications would get corrupted. To prevent this, the researchers restricted write-access to the modified memory module for all processes except the target virtual system.<\/p>\n

So what does this accomplish? If the processor thinks that the memory capacity is twice as large as it actually is, then each pair of virtual addresses maps to only one physical memory cell. This allows a scenario where a real memory area is simultaneously used by a protected virtual OS \u2014 and accessible to another, malicious, application. The latter won\u2019t write to the memory cells, but can read what the virtual OS writes to them. This is precisely the scenario that AMD\u2019s SEV technology is designed to prevent, but in this case it proves ineffective \u2014 both memory access protection and encryption are bypassed.<\/p>\n

We\u2019re glossing over many important details of the study, but the main takeaway is that this malicious memory module creates a situation where the supposedly highly-secure data of a virtual machine becomes accessible to an external application. Yes, this is an extremely complex attack \u2014 requiring physical access to the server in addition to \u201chacking\u201d the server\u2019s software to gain the highest access privileges. However, compare this to a previous study<\/a>, where a similar result was achieved using an extremely expensive ($170,000) hardware device that intercepted data transmission between the processor and the memory module in real time.<\/p>\n

In the BadRAM attack, the SPD chip is modified using a simple kit consisting of a microcomputer and readily available software costing around $10 in total. After modification, physical access to the server is no longer required, and all subsequent attack stages can be carried out remotely. In some memory modules, even remote rewriting of the SPD data may be possible.<\/p>\n

Fortunately, the vulnerabilities<\/a> exploited in this attack have been patched in firmware updates for AMD EPYC 3rd<\/sup> Gen and 4th<\/sup> Gen processors. The protection technology now includes a mechanism capable of detecting \u201cmalicious\u201d memory modules. By the way, the researchers also tested Intel\u2019s TDX technology, which appears to already have a similar RAM integrity-check in place, making attacks like BadRAM impossible.<\/p>\n

The concept of a trusted execution environment is designed for work in highly hostile environments. We discussed a scenario where the owner of a virtual OS doesn\u2019t trust the hosting provider. Even under such paranoid conditions, avoiding errors remains a significant challenge \u2014 as demonstrated by the BadRAM study. The authors generally argue that TEE system developers rely too heavily on the difficulty of extracting data from RAM, and illustrate how even the most sophisticated security systems can be bypassed using relatively simple means.<\/p>\n","protected":false},"excerpt":{"rendered":"

European researchers have discovered a vulnerability in AMD processors that can be exploited by modifying RAM modules.<\/p>\n","protected":false},"author":665,"featured_media":52850,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1999,3051],"tags":[3116,4410,1104],"class_list":{"0":"post-52849","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"tag-cpu","10":"tag-ram","11":"tag-virtualization"},"hreflang":[{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/badram-cpu-attack\/52849\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/badram-cpu-attack\/38843\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/badram-cpu-attack\/28668\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/www.kaspersky.com\/blog\/tag\/ram\/","name":"RAM"},"_links":{"self":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/52849","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=52849"}],"version-history":[{"count":1,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/52849\/revisions"}],"predecessor-version":[{"id":52851,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/52849\/revisions\/52851"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/52850"}],"wp:attachment":[{"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=52849"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=52849"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=52849"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}