TRRespass: Exploiting the Many Sides of Target Row Refresh

Abstract

After a plethora of high-profile RowHammer attacks, CPU and DRAM vendors scrambled to deliver what was meant to be the definitive hardware solution against the RowHammer problem: Target Row Refresh (TRR). A common belief among practitioners is that, for the latest generation of DDR4 systems that are protected by TRR, RowHammer is no longer an issue in practice. However, in reality, very little is known about TRR. How does TRR exactly prevent RowHammer? Which parts of a system are responsible for operating the TRR mechanism? Does TRR completely solve the RowHammer problem or does it have weaknesses?In this paper, we demystify the inner workings of TRR and debunk its security guarantees. We show that what is advertised as a single mitigation mechanism is actually a series of different solutions coalesced under the umbrella term Target Row Refresh. We inspect and disclose, via a deep analysis, different existing TRR solutions and demonstrate that modern implementations operate entirely inside DRAM chips. Despite the difficulties of analyzing in-DRAM mitigations, we describe novel techniques for gaining insights into the operation of these mitigation mechanisms. These insights allow us to build TRRespass, a scalable black-box RowHammer fuzzer that we evaluate on 42 recent DDR4 modules.TRRespass shows that even the latest generation DDR4 chips with in-DRAM TRR, immune to all known RowHammer attacks, are often still vulnerable to new TRR-aware variants of RowHammer that we develop. In particular, TRRespass finds that, on present-day DDR4 modules, RowHammer is still possible when many aggressor rows are used (as many as 19 in some cases), with a method we generally refer to as Many-sided RowHammer. Overall, our analysis shows that 13 out of the 42 modules from all three major DRAM vendors (i.e., Samsung, Micron, and Hynix) are vulnerable to our TRR-aware RowHammer access patterns, and thus one can still mount existing state-of-the-art system-level RowHammer attacks. In addition to DDR4, we also experiment with LPDDR4(X) 1 chips and show that they are susceptible to RowHammer bit flips too. Our results provide concrete evidence that the pursuit of better RowHammer mitigations must continue. 2 We turn off the in-DRAM RowHammer mitigation mechanism by disabling REFRESH commands, as we explain in Section V.

Stop! Hammer time

“…While DRAM occasionally remaps two logically-adjacent rows to different internal locations [11], these remaps (and thus, internal adjacency) can be revealed via established methods. In particular, prior work [11,15,30,34] uses the success or failure of Rowhammer attacks themselves-which require physicallyproximate rows-to infer row adjacency.…”

“…Refresh-Centric. Finally, refresh-centric mitigations (e.g., [4,15,32,37,48,60,62]) seek to refresh potential victim rows before they experience bit flips. More specifically, these defenses use a set of hardware and-in some cases-software mechanisms to identify potential victim rows.…”

“…To date, DRAM vendors have shown years of unwillingness (perhaps due to economic reasons) to provide a comprehensive solution to Rowhammer. Despite vendor claims that their defenses prevent all Rowhammer attacks [38,42], recent work [14,15] demonstrates that Rowhammer exploits remain viable. Given the blackbox nature of vendor mitigations, system administrators are left largely powerless to prevent these attacks, just as they were the original exploits.…”

On DRAM Rowhammer and the Physics of Insecurity

“…The confluence of DRAM ubiquity, increasing RH susceptibility, and the possibility to use this unique disturb to gain unauthorized access has created a major hardware security concern across all modern computing systems [7] from cloud servers [8] through personal computers [4], [9] to mobile phones [10].…”

“…Such approaches are regarded as competitive advantages by the DRAM manufacturers and so remain opaque to the users. The problem is that every mitigation up until now has been hacked [7], [11], [12] leaving all compute systems in jeopardy.…”