{"id":1192,"date":"2024-12-12T02:51:40","date_gmt":"2024-12-12T02:51:40","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=1192"},"modified":"2024-12-12T02:51:40","modified_gmt":"2024-12-12T02:51:40","slug":"amd-data-center-chips-vulnerable-to-revealing-data-through-badram-attack","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=1192","title":{"rendered":"AMD data center chips vulnerable to revealing data through \u2018BadRAM\u2019 attack"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

AMD\u2019s Secure Encrypted Virtualization (SEV), meant to protect processor memory from prying eyes in virtual machine (VM) environments, can be tricked into giving access to its encrypted memory contents using a test rig costing less than $10, researchers have revealed.<\/p>\n

Dubbed \u201cBadRAM\u201d by researchers from the University of L\u00fcbeck in Germany, KU Leven in Belgium, and the University of Birmingham in the UK, the proposed attack is conceptually simple as well as cheap: trick the CPU into thinking it has more memory than it really has, using a rogue memory module, and get it to write its supposedly secret memory contents to the \u201cghost\u201d space.<\/p>\n

The researchers achieved this using a test rig anyone could buy, consisting of a Raspberry Pi Pico, costing a few dollars, and a DIMM socket to hold DDR4\/5 RAM modules. First, they manipulated the serial presence detect (SPD) chip built into the memory module to misreport the amount of onboard memory when booting up \u2014 the \u201cBadRAM\u201d part of the attack.<\/p>\n

This created two physical addresses referring to the same DRAM location, which, using some reverse engineering to locate these memory aliases, gave them access to memory contents, bypassing the system\u2019s trusted execution environment (TEE).<\/p>\n

The accessible memory contents were still encrypted, but even getting that far shouldn\u2019t have been possible. The whole point of AMD\u2019s SEV TEE is that it stops attackers from gaining access to memory by encrypting its contents, something that is especially important in cloud data centers where the physical machines are not under an organization\u2019s control.\u00a0 Because of this, AMD\u2019s SEV is widely used in the cloud industry by every major platform provider, which makes the discovery of the weakness significant.<\/p>\n

Does BadRAM defeat encryption?<\/h2>\n

This is where the attack becomes more hypothetical. An attacker using BadRAM has access to the data used by the microprocessor, but not in its unencrypted plaintext form. However, according to Jo Van Bulck of the University of KU Leuven in Belgium, that doesn\u2019t mean that the data can\u2019t be manipulated in other ways.<\/p>\n

\u201cWith BadRAM, the exploit is not just that you can read the encrypted contents, but that you can overwrite the encrypted contents,\u201d he told CSO Online via email. This is a function of the static nature of encryption, which encrypts values in ciphertext in a way an attacker can predict.<\/p>\n

He used the example of a bank account showing an encrypted balance of $100. If this figure was then reduced by subsequent spending, an attacker could in theory replace it with the higher original, but still encrypted, $100 value.\u00a0<\/p>\n

\u201cThere\u2019s basically no means in the AMD CPU to distinguish this old, outdated value from the correct, current value,\u201d said Van Bulck.<\/p>\n

An attacker needs physical access<\/h2>\n

The above is a form of replay attack, and would presumably require time and additional software to interact with the encrypted data. That would present practical challenges for any attacker in a large data center environment where monitoring is taken seriously.<\/p>\n

However, perhaps the biggest limitation is that any attack would require physical access to the system in which the virtual machine was running. While this is plausible in an insider or rogue admin scenario, it does reduce the possibility of an attack, compared to a remote or software-only exploit.<\/p>\n

Could BadRAM be used against non-AMD systems?<\/h2>\n

It seems less likely that BadRAM attacks could be used against non-AMD processors, the researchers said. Intel\u2019s Software Guard Extensions (SGX) and Trusted Domain Extensions (TDX), and Arm\u2019s upcoming Confidential Compute Architecture (CCA) also use TEEs, but employ countermeasures against memory aliasing attacks.<\/p>\n

Nevertheless, according to Van Bulck, in Intel\u2019s case, it would depend on the generation of SGX being used. The older SGX, dating back to 2015, could be affected, but the impact would be minimal because of strong encryption.<\/p>\n

However, the more recent TDX and SGX trusted-execution technologies could not be compromised, thanks to built-in anti BadRAM defenses. The impact on Arm\u2019s CCA (Confidential Compute Architecture) is as yet unclear.<\/p>\n

\u201cWe think BadRAM should theoretically apply to these upcoming platforms, but they have not yet been publicly released,\u201d Van Bulck said. \u201cWe hope CCA platforms will have similar checks in place to detect BadRAM attack attempts at boot time, which may, however, be further complicated by the inherent heterogeneity of the Arm landscape.\u201d<\/p>\n

AMD\u2019s BadRAM fix<\/h2>\n

Revealed to AMD by the researchers in February, the vulnerability is tracked as CVE-2024-21944, and relates specifically to the company\u2019s third and fourth generation EPYC enterprise processors. \u00a0<\/p>\n

\u201cAMD recommends utilizing memory modules that lock SPD, as well as following physical security best practices,\u201d its advisory states. It has also issued firmware updates, although these will vary due to each OEM\u2019s BIOS, it said.<\/p>\n

The company said it planned to make mitigation reminders prominent. \u201cThere is specific status information that is provided and available for a Host OS\/Hypervisor, and also available for a Virtual Machine (Guest) to indicate that the mitigation has been deployed,\u201d it said.<\/p>\n

The bottom line<\/h2>\n

It would be easy to dismiss BadRAM as overblown. It has a fancy name and a memorable logo faintly reminiscent of a disappointed character from Angry Birds.<\/p>\n

The counter argument is that this is the sort of basic weakness chip makers should spot without having to have it pointed out to them. Using a logo and a name that IT teams hear about is one way to get vendors and their customers to fix problems and apply patches in an industry where patches are often put off for another day.<\/p>\n

BadRAM is the second significant vulnerability in AMD hardware since the summer. In August, a security vendor released details of \u201cSinkclose<\/a>\u201d( CVE-2023-31315), a flaw affecting nearly all AMD EPYC series and Ryzen series<\/a> CPUs.<\/p>\n\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

AMD\u2019s Secure Encrypted Virtualization (SEV), meant to protect processor memory from prying eyes in virtual machine (VM) environments, can be tricked into giving access to its encrypted memory contents using a test rig costing less than $10, researchers have revealed. Dubbed \u201cBadRAM\u201d by researchers from the University of L\u00fcbeck in Germany, KU Leven in Belgium, […]<\/p>\n","protected":false},"author":0,"featured_media":1193,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-1192","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1192"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1192"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/1192\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/1193"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1192"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1192"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1192"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}