Modern memory is still vulnerable to Rowhammer vulnerabilities — Phoenix root privilege escalation attack proves that Rowhammer still smashes DDR5 security to bits

News
By published

Neither TRR, ECC, nor ODECC can save you from this one.

A hammer smashing a laptop computer.
(Image credit: Getty Images)

Scientists from the Computer Security Group (COMSEC) at the ETH Zürich college, in conjunction with Google, have published a proof-of-concept attack on DDR5 RAM called Phoenix, with the CVE number 2025-6202. The new attack causes bit-flips in memory, leading to a set of vulnerabilities that includes high-level privilege escalation. Phoenix adeptly bypasses DDR5's preventive measures for Rowhammer-style attacks, and neither ECC nor ODECC (on-die ECC) are of help.

It's worth noting that COMSEC only tested the attacks on an AMD Zen 4 platform, against 15 SK hynix DDR5 DIMMs from 2021-2024. The team states it chose the largest DRAM vendor, as the analysis is time-intensive even with the help of dedicated FPGA test boards. Having said that, the research is part of a Google-led effort for better RAM security in cooperation with JEDEC, the consortium that defines memory standards. It's also not the first time that COMSEC has worked on RAM security, having previously cooperated with VUSec to create the TRRespass attack.

There's no bulletproof mitigation for this issue yet — at least for the tested SK hynix DIMMs — but the researchers state that increasing the row refresh rate (tREFI) in the machine's UEFI by 3 times down to around 1.3 μs makes the attacks unlikely to succeed. However, that comes at a steep cost, as a benchmark with the SPEC CPU2017 suite revealed a nasty 8.4% performance hit. COMSEC says there's an impending BIOS update for AMD client systems to address this problem, but couldn't verify its effectiveness as of the date of its publication.

Bruno Ferreira
Bruno Ferreira
Contributor

Bruno Ferreira is a contributing writer for Tom's Hardware. He has decades of experience with PC hardware and assorted sundries, alongside a career as a developer. He's obsessed with detail and has a tendency to ramble on the topics he loves. When not doing that, he's usually playing games, or at live music shows and festivals.

7 Comments Comment from the forums
  • Li Ken-un
    I have an AMD Ryzen Pro machine with memory encryption turned on. I wonder if that confers any protection from rowhammer.
    Reply
  • bit_user
    Nice article, Bruno Ferreira! Thanks & welcome!
    : )
    The article said:
    Phoenix's creators tested specific scenarios and had a 100% success rate in replicating attacks that manipulate Page Table Entries (PTE),
    I wonder whether Kernel Address Space Layout Randomization can be used to mitigate, or if x86 system architecture mandates it reside at a fixed address? According to wikipedia, page table entries are not currently subject to randomization, but it doesn't say they can't be.
    https://en.wikipedia.org/wiki/Address_space_layout_randomization#Limitations
    The article said:
    Those circumstances led to the creation of the PRAC (Per-Row Activation Counting) JEDEC standard, first announced in April 2024 for a future DD5 revision.
    I assume you meant "DDR"?

    The final point I'd mention is that this attack is not without symptoms. Many recent side-channel vulnerabilities involve spying, but not modifying the memory of the victim, and therefore have relatively low potential for detection. However, RowHammer is quite a violent and somewhat indiscriminate exploit, in that it's likely to cause side-effects (e.g. crashing processes or even kernel panics), by the time the attacker finally flips a bit that does something useful. Therefore, one bit of solace I think we can take is that close monitoring of hosts could probably detect and even isolate a victim, by the time the attacker achieves anything useful.
    Reply
  • setx
    Li Ken-un said:
    I have an AMD Ryzen Pro machine with memory encryption turned on. I wonder if that confers any protection from rowhammer.
    From direct privilege escalation – maybe, from memory corruption – no.
    Reply
  • bit_user
    Li Ken-un said:
    I have an AMD Ryzen Pro machine with memory encryption turned on. I wonder if that confers any protection from rowhammer.
    Sadly, I'd assume not. I expect memory encryption simply changes the meaning of the bits, without affecting information density or adding any more integrity checks. Since RowHammer relies on somewhat randomly flipping bits until "something useful" happens, changing the meaning of specific bits has no real value as a defense.

    Memory compression might help a bit more, at least in so far as affecting layout variability and potentially increasing the amount of collateral damage from such an attack (though, I'm not sure if page tables would ever be subject to compression). If you cause a kernel panic or trigger other sorts of fault monitoring, then the actual success rate of the attack is compromised.

    I wonder if another mitigation tactic could involve layering another level of ECC. So, what if you had in-band ECC atop out-of-band ECC? At least for critical in-memory structures that have fixed addresses? It would further increase the amount of time for a successful attack. In the meantime, the system would be throwing loads of ECC errors, which could quickly grab the attention of monitoring software. If the ECC errors weren't localized to a single DIMM, but spread evenly across all DIMMs, that would help distinguish RowHammer from a normal harware fault.
    Reply
  • pjmelect
    This is rubish row hammer assults do not work for many reasons, the main one being that if it did then computers would be crashing all over the place.
    Reply
  • Li Ken-un
    bit_user said:
    If you cause a kernel panic or trigger other sorts of fault monitoring, then the actual success rate of the attack is compromised.
    That might be good enough. For some, a hard crash is better than continuing as if nothing were amiss.
    Reply
  • bit_user
    pjmelect said:
    This is rubish row hammer assults do not work for many reasons, the main one being that if it did then computers would be crashing all over the place.
    RowHammer doesn't happen by accident, which I think might be the point of misunderstanding. Naive code that repeatedly reads from or writes to the same memory location will simply hit the cache hierarchy instead of DRAM. That's what's saving us from this "crashing all over the place" scenario you describe.

    In order to mount a RowHammer attack that has any chance of success, the attacker must take explicit measures to circumvent the cache hierarchy.

    BTW, there's a RowHammer test in the Memtest86 program from PassMark. I've never seen it fail, in several systems I've run it on, which suggests it's not a very strong implementation. It's described, here:
    "Starting from MemTest86 v6.2, potentially two passes of row hammer testing are performed. On the first pass, address pairs are hammered at the highest possible rate. If errors are detected on the first pass, errors are not immediately reported and a second pass is started. In this pass, address pairs are hammered at a lower rate deemed as the worst case scenario by memory vendors (200K accesses per 64ms). If errors are also detected in this pass, the errors are reported to the user as normal. However, if only the first pass produces an error, a warning message is instead displayed to the user."

    https://www.memtest86.com/tech_individual-test-descr.html#hammer
    Yup, it turns out they only tell you if the memory can't survive the JEDEC target rate of 200k accesses per 64 ms, which is much lower than the peak achievable rate. I'll bet they got too many complaints from memory vendors, when they exposed the results of the full-rate testing.
    Reply