{"id":24569,"date":"2025-08-20T15:44:19","date_gmt":"2025-08-20T11:44:19","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/?p=24569"},"modified":"2025-08-20T15:44:19","modified_gmt":"2025-08-20T11:44:19","slug":"retbleed-practical-exploitation","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/retbleed-practical-exploitation\/24569\/","title":{"rendered":"Practical exploitation of Retbleed on AMD CPUs"},"content":{"rendered":"

In a new paper<\/a>, Google researchers Matteo Rizzo and Andy Nguyen have detailed an improved Retbleed attack scenario. As we\u2019ve explained<\/a> in a previous post, the original Retbleed attack exploited vulnerabilities in AMD\u2019s Zen and Zen 2, as well as Intel\u2019s Kaby Lake and Coffee Lake CPUs. Hardware vulnerabilities of this kind are extremely difficult to exploit in realistic settings, which is why the various forms of Spectre<\/a> and derivative attacks like Retbleed<\/a> have remained largely theoretical. Despite this, both CPU manufacturers and software developers have implemented methods to mitigate them. The essence of the new Google research is to demonstrate how the effectiveness of the Retbleed attack can be increased. Without fundamentally changing the attack\u2019s architecture, they were able to leverage features of AMD Zen 2 CPUs to read arbitrary data from RAM.<\/p>\n

Retbleed in a nutshell<\/h2>\n

Like Spectre, Retbleed exploits a feature called branch prediction<\/a> in a computer\u2019s CPU. Branch prediction allows the processor to speculatively execute instructions without waiting for the results of previous computations. Sometimes such predictions are wrong, but normally this only results in a slight, imperceptible slowdown in the application\u2019s performance.<\/p>\n

In 2018, the Spectre attack showed that incorrect predictions can be used to steal secrets. This is possible due to two key characteristics. First, the branch prediction system can be trained to access a memory area containing secret data, which then gets loaded into the CPU cache. Second, a way was found to extract this secret data from the cache through a side channel by measuring the execution time of a specific instruction.<\/p>\n

Retbleed can be considered an evolution of the Spectre v2 attack: it also exploits the characteristics of the branch prediction system, but differs in how it injects instructions. What\u2019s more, Retbleed can bypass the technology used to protect against Spectre v2, and therefore threatens systems running on more modern hardware. Retbleed remains difficult to implement. A demonstration<\/a> in ideal conditions by the authors of the original research took a full 90 minutes to extract the secret (in that case a user password).<\/p>\n

What the Google researchers accomplished<\/h2>\n

The researchers from Google were able to significantly accelerate a Retbleed attack. The key takeaway from their work is that arbitrary sections of RAM at 13 KB\/s can be read. The accuracy of extracting secret data from the cache is also crucial for such attacks, and in this case it was one hundred percent. The experts demonstrated how the security systems of the operating system kernel \u2013 specifically the Linux kernel \u2013 can be bypassed. Another significant improvement they made was the use of an attack known as Speculative ROP<\/a>, which they modified to evade the very same defenses designed for Spectre v2.<\/p>\n

According to the researchers, the only limitation of their exploit is the need to know the system\u2019s kernel configuration in advance. This isn\u2019t a major hurdle because many systems use common, standard configurations. Even for unknown configurations, attackers can perform a preliminary analysis.<\/p>\n

Should we expect Retbleed attacks in the wild?<\/h2>\n

Most such attacks explore a scenario where malicious code with low privileges runs on a standard computer \u2013 ultimately gaining access to sensitive data. However, the same could be said of attacks using traditional malware. If an attacker has already managed to execute arbitrary code on a system, they don\u2019t necessarily need to resort to extremely complex methods for privilege escalation. There are often simpler ways to achieve the same result, such as exploiting a vulnerability in an application or system software.<\/p>\n

Attacks like Spectre and Retbleed pose the greatest danger to cloud systems. For a cloud provider, it\u2019s critically important that clients whose virtual machines share the same hardware can\u2019t gain access to other users\u2019 data or hypervisor information. Google\u2019s researchers claim that this new variant of the Retbleed attack allows for exactly that. As a result, Google has stopped using servers with AMD Zen 2 architecture CPUs in its own cloud services for tasks that involve clients executing arbitrary code. So it does seem they\u2019re taking this threat seriously.<\/p>\n\n","protected":false},"excerpt":{"rendered":"

Google experts have demonstrated how complex hardware vulnerabilities in CPUs can be effectively exploited.<\/p>\n","protected":false},"author":665,"featured_media":24570,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[2849,2782,1616],"class_list":{"0":"post-24569","1":"post","2":"type-post","3":"status-publish","4":"format-standard","5":"has-post-thumbnail","7":"category-business","8":"category-enterprise","9":"category-smb","10":"tag-hardware-vulnerabilities","11":"tag-side-channel-attack","12":"tag-spectre"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/retbleed-practical-exploitation\/24569\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/retbleed-practical-exploitation\/29461\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/retbleed-practical-exploitation\/29402\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/retbleed-practical-exploitation\/40322\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/retbleed-practical-exploitation\/54169\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/retbleed-practical-exploitation\/29590\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/retbleed-practical-exploitation\/35333\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/retbleed-practical-exploitation\/34964\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/hardware-vulnerabilities\/","name":"hardware vulnerabilities"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24569","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/users\/665"}],"replies":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/comments?post=24569"}],"version-history":[{"count":2,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24569\/revisions"}],"predecessor-version":[{"id":24572,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24569\/revisions\/24572"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/24570"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=24569"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=24569"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=24569"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}