To use our site, you agree to the use of cookies and data processing according to our privacy statement.
Close
Search

Security Highlight: The Return of Rowhammer

Do you remember the Rowhammer attack? This surprising attack published in 2015 exploited cross-talk between DRAM memory cells. In this type of memory, data is stored in tiny capacitors that are periodically refreshed. However, due to the extremely small distances between adjacent cells, there is a risk that writing one cell accidentally also triggers a state change in its neighbor. At the time, it was shown that by using ‘aggressor’ lines surrounding ‘victim’ lines, it was possible to make an exploitable memory change, for instance, compromise a cryptographic key.

Since 2015 memory chip vendors have worked on mitigations and introduced TRR (Target Row Refresh). This technique, which recognizes a Rowhammer attack by the pattern and frequency of writes automatically, refreshes the risk cells. TRR is implemented in DDR4 chips.

Recently, researchers found that the TRR technique can be circumvented because this technique relies too much on the behavior of the original attack. With a derived method called ‘Rowhammer Blacksmith,’ they use different patterns and frequencies of writing the aggressor lines. As a result, detection and mitigation by TRR are prevented. The researchers performed experiments on 40 different DDR4 chips and confirmed that all of them are vulnerable to Blacksmith.

There are two important lessons in this incident. Firstly, Rowhammer is, in essence, an FI (Fault Injection) method. But unlike many of these methods, Rowhammer is a pure software attack that can be executed remotely. With this new report, we have to conclude that all devices using DRAM allow malicious users to attack other users. Even when a solid logical user separation is in place, they can compromise assets. We believe that Rowhammer deserves more attention as it may become a very scalable FI attack vector.

Secondly, we learn that mitigating attacks are prone to mistakes. Here we may see a pattern that often occurs, where developers build a solution based on their understanding of the problem without seeking independent verification. With such an approach, the chances are that the solution is tailored to (some) symptoms of the problem but fails to address the deeper cause.

We recommend (DDR) chipmakers to seek independent problem analysis and solution verification to maximize the probability for robust and future-proof product improvements.

If you have any questions, contact us at inforequest@riscure.com.