{"id":24771,"date":"2025-10-03T20:02:49","date_gmt":"2025-10-03T16:02:49","guid":{"rendered":"https:\/\/me-en.kaspersky.com\/blog\/phoenix-rowhammer-attack\/24771\/"},"modified":"2025-10-03T20:02:58","modified_gmt":"2025-10-03T16:02:58","slug":"phoenix-rowhammer-attack","status":"publish","type":"post","link":"https:\/\/me-en.kaspersky.com\/blog\/phoenix-rowhammer-attack\/24771\/","title":{"rendered":"Phoenix: a Rowhammer attack vs. DDR5 memory"},"content":{"rendered":"

In September 2025, researchers at ETH Zurich (the Swiss Federal Institute of Technology) published a paper<\/a> introducing Phoenix, a modification of the Rowhammer attack that works on DDR5 memory modules. The authors not only demonstrated the new attack\u2019s effectiveness against 15 tested modules, but also proposed three practical use cases: reading and writing data from memory, stealing a private encryption key stored in memory, and bypassing Linux\u2019s sudo utility protections to escalate privileges.\n<\/p>\n

The Rowhammer attack: a brief history<\/h2>\n

\nTo understand this rather complex study, we need to first briefly revisit the history of Rowhammer. The Rowhammer attack was first described in a 2014 research paper<\/a>. Back then, researchers from both Carnegie Mellon University and Intel showed how repeatedly accessing rows of memory cells could cause adjacent memory cells to change value. These neighboring cells could contain critical data \u2014 the alteration of which could have serious consequences (such as privilege escalation).<\/p>\n

This happens because each cell in a memory chip is essentially a capacitor: a simple component that can hold an electrical charge for only a short time. That\u2019s why such memory is volatile: turn off the computer or server, and the data disappears. For the same reason the charge in cells must be frequently refreshed \u2014 even if no one is accessing that memory region<\/em>.<\/p>\n

Memory cells aren\u2019t isolated; they\u2019re organized in rows and columns, interconnected in ways that can cause interference. Accessing one row can affect a neighboring row; for example, refreshing one row can corrupt data in another. For years, this effect was only known to memory manufacturers \u2014 who tried their best to mitigate it in order to improve reliability. But as cells became smaller and therefore packed more tightly together, the \u201crow hammering\u201d effect became exploitable in real-world attacks.<\/p>\n

After the Rowhammer attack was demonstrated, memory developers began to introduce defenses, resulting in Target Row Refresh (TRR) hardware technology. In theory, TRR is simple: it monitors aggressive access to rows and, if detected, forcibly refreshes adjacent rows. In practice, it wasn\u2019t so effective. In 2021, researchers described the Blacksmith attack<\/a>, which bypassed TRR by using more sophisticated memory-cell access patterns.<\/p>\n

Developers adapted again \u2014 adding even more advanced defenses against Rowhammer-like attacks in DDR5 modules and increasing the enforced refresh rate. To further impede new attacks, manufacturers avoided disclosing which countermeasures were in place. This led many to believe that DDR5 had effectively solved the Rowhammer problem. However, just last year, researchers from the same ETH Zurich managed to successfully attack<\/a> DDR5 modules \u2014 albeit under certain conditions: the memory had to be paired with AMD Zen 2 or Zen 3 CPUs, and, even then, some modules remained unaffected.\n<\/p>\n

Features of the new attack<\/h2>\n

\nTo develop Phoenix, the researchers reverse-engineered the TRR mechanism. They analyzed its behavior under various memory row access patterns and checked whether the protection triggered for adjacent rows. It turned out that TRR has become significantly more complex, and previously known access patterns no longer work \u2014 the protection now correctly flags those patterns as potentially dangerous and forcibly refreshes adjacent rows. As a result, the researchers discovered that after 128 TRR-tracked memory accesses, a \u201cwindow of opportunity\u201d of 64 accesses appears, during which defenses are weaker. It\u2019s not that the protection system completely fails, but its responses are insufficient to prevent a value change in a targeted memory cell. The second window presents itself after accessing memory cells over the course of 2608 refresh intervals.<\/p>\n

The researchers then studied these vulnerable points in detail to deliver a highly targeted strike on memory cells while knocking out the defenses. Put simply, the attack works like this: malicious code performs a series of dummy accesses that effectively lull the TRR mechanism into a false sense of security. Then the active phase of the attack occurs, which ultimately modifies the target cell value. As a result, the team confirmed that the attack reliably worked against all 15 tested DDR5 modules manufactured by SK Hynix, one of the market leaders.\n<\/p>\n

Three real-world attack scenarios<\/h2>\n

\nA realistic attack must change a value in a precisely defined memory region \u2014 a difficult task. Firstly, an attacker needs detailed knowledge of the target software. They must bypass multiple conventional security controls, and missing the target by just one or two bits can result in a system crash instead of a successful hack.<\/p>\n

The Swiss researchers set out to prove that Phoenix could be used to cause real-world damage. They evaluated three attack scenarios. The first (PTE) involved accessing the page table to create conditions for arbitrary reading\/writing of RAM data. The second (RSA) aimed to steal an RSA-2048 private encryption key from memory. The third (sudo) involved bypassing the protections of the standard Linux sudo utility with the aim of privilege escalation. The study\u2019s final results are shown in this table:<\/p>\n

[phoenix-rowhammer-attack-results.jpg]<\/p>

\"Phoenix<\/a>

Phoenix attack effectiveness. Source<\/a><\/p><\/div>\n

For some modules, the first attack variant (128 refresh intervals) was effective, while for others only the second (2608 intervals) method worked. In some experiments the RSA key theft and sudo exploits didn\u2019t succeed. However, a method for arbitrary memory read\/write was found for all modules, and the exploitation time was relatively short for this class of attacks \u2014 from about five seconds up to seven minutes. That\u2019s enough to demonstrate that Rowhammer attacks pose a real risk, albeit in a highly constrained set of scenarios.\n<\/p>\n

Relevance and countermeasures<\/h2>\n

\nThe Phoenix attack shows that Rowhammer-style attacks can be carried out against DDR5 modules just as effectively as on DDR4 and DDR3. Though modules from a just single vendor were tested and the researchers uncovered a fairly simple weakness in that vendor\u2019s TRR algorithm that will most likely be easy to fix, this is a significant step forward in the security research of memory modules.<\/p>\n

The authors proposed several countermeasures against Rowhammer-type attacks. First, reducing the enforced refresh interval across all cells can significantly impede the attack. This may increase power consumption and chip temperature, but it\u2019s a straightforward solution. Second, memory with an error correction code (ECC) can be used. This complicates Rowhammer attacks, although \u2014 somewhat paradoxically \u2014 it doesn\u2019t make them completely impossible<\/a>.<\/p>\n

Beyond these obvious measures, the authors mention two more. The first is the Fine Granularity Refresh protection method, which is already being implemented. Built into the processor\u2019s memory controller, it modifies memory-cell refresh behavior in order to resist Rowhammer attacks. As for the second, the researchers urge memory-module and chip developers to stop relying on proprietary security measures (\u201csecurity through obscurity\u201d). Instead, they recommend adopting an approach common in cryptography \u2014 where security algorithms are publicly available and subject to independent testing.<\/p>\n","protected":false},"excerpt":{"rendered":"

Phoenix, a new variant of the Rowhammer attack, makes it possible to attack DDR5 memory modules.<\/p>\n","protected":false},"author":665,"featured_media":24774,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1318,1916,1917],"tags":[1613,2662,268],"class_list":{"0":"post-24771","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","11":"tag-memory","12":"tag-vulnerabilities"},"hreflang":[{"hreflang":"en-ae","url":"https:\/\/me-en.kaspersky.com\/blog\/phoenix-rowhammer-attack\/24771\/"},{"hreflang":"en-in","url":"https:\/\/www.kaspersky.co.in\/blog\/phoenix-rowhammer-attack\/29700\/"},{"hreflang":"en-gb","url":"https:\/\/www.kaspersky.co.uk\/blog\/phoenix-rowhammer-attack\/29588\/"},{"hreflang":"es-mx","url":"https:\/\/latam.kaspersky.com\/blog\/phoenix-rowhammer-attack\/28647\/"},{"hreflang":"es","url":"https:\/\/www.kaspersky.es\/blog\/phoenix-rowhammer-attack\/31534\/"},{"hreflang":"it","url":"https:\/\/www.kaspersky.it\/blog\/phoenix-rowhammer-attack\/30189\/"},{"hreflang":"ru","url":"https:\/\/www.kaspersky.ru\/blog\/phoenix-rowhammer-attack\/40627\/"},{"hreflang":"tr","url":"https:\/\/www.kaspersky.com.tr\/blog\/phoenix-rowhammer-attack\/13876\/"},{"hreflang":"x-default","url":"https:\/\/www.kaspersky.com\/blog\/phoenix-rowhammer-attack\/54528\/"},{"hreflang":"pt-br","url":"https:\/\/www.kaspersky.com.br\/blog\/phoenix-rowhammer-attack\/24389\/"},{"hreflang":"de","url":"https:\/\/www.kaspersky.de\/blog\/phoenix-rowhammer-attack\/32786\/"},{"hreflang":"ru-kz","url":"https:\/\/blog.kaspersky.kz\/phoenix-rowhammer-attack\/29803\/"},{"hreflang":"en-au","url":"https:\/\/www.kaspersky.com.au\/blog\/phoenix-rowhammer-attack\/35532\/"},{"hreflang":"en-za","url":"https:\/\/www.kaspersky.co.za\/blog\/phoenix-rowhammer-attack\/35156\/"}],"acf":[],"banners":"","maintag":{"url":"https:\/\/me-en.kaspersky.com\/blog\/tag\/hardware\/","name":"hardware"},"_links":{"self":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24771","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=24771"}],"version-history":[{"count":1,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24771\/revisions"}],"predecessor-version":[{"id":24773,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/posts\/24771\/revisions\/24773"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media\/24774"}],"wp:attachment":[{"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/media?parent=24771"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/categories?post=24771"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/me-en.kaspersky.com\/blog\/wp-json\/wp\/v2\/tags?post=24771"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}