What is RowPress and how is it different from RowHammer?
RowHammer, an attack mounted from software to violate memory integrity in DRAM was first discovered in 2014. Data in DRAM is stored in capacitors and arranged in rows and columns, which must be refreshed periodically to prevent data corruption. The key insight behind the RowHammer attack is that accessing data in one DRAM row disturbs the charge in neighboring rows. If the same rows are accessed rapidly (hammering), bit-flips in neighboring rows can be induced before a refresh occurs.
Over the past decade, DRAM manufacturers have implemented countermeasures such as Targeted Row Refresh (TRR), which tracks the frequency of accessed rows and preemptively refreshes vulnerable neighboring rows, and on-die ECC, which corrects bit-flips before the data is returned to software. Security researchers have also continued to refine the basic RowHammer attack technique in order to bypass these mitigations.
In the fall of 2023, researchers from ETH Zurich reported another attack called RowPress. Similar to RowHammer, RowPress can be used to violate memory integrity in DRAM from software, but accomplishes this using orders of magnitude fewer accesses to DRAM. This means that countermeasures such as TRR, which are tuned to prevent RowHammer will not prevent RowPress.
RowPress takes advantage of the fact that the longer a DRAM row is kept “open” (the row is retained in the row buffer instead of written back to the memory array), the greater the likelihood of bit-flips in neighboring rows. The ability to keep rows open is important for performance reasons, as subsequent accesses to data in the same row is faster if the row is kept open. RowHammer repeatedly closes and opens rows, whereas RowPress focuses on keeping rows open as long as possible, which greatly reduces the number of accesses required before bit-flips occur.
How realistic is this attack in practice?
In essence, both RowHammer and RowPress are fault injection (FI) attacks that can be performed from software. Compared to other types of FI attacks such as voltage or clock glitching, to our knowledge there have been no publicly reported security incidents where RowHammer or RowPress was used, however many speculate that real-world attacks are imminent. In a research setting, there have been many successful demonstrations of RowPress and RowHammer attacks targeting commercial off-the-shelf DRAM modules from all the major vendors.
Performing a successful RowHammer or RowPress attack requires the capability to bypass caching, knowledge of virtual-to-physical address mapping, and a mechanism to force victim assets into DRAM rows adjacent to attacker-accessible rows. This often requires a significant amount of reverse engineering effort compared to what is required to perform a voltage or clock glitching attack. However, compared to traditional fault injection attacks RowHammer and RowPress do not require specialized hardware tools, modifications of the target hardware, or physical access to the target. Once an attack has been demonstrated on a specific software/hardware configuration, it is easy to reproduce by non-experts.
Recommendations for risk management
The approaches to risk management for RowPress and RowHammer attacks depend on the sensitivity of data being processed. For critical applications, we recommend avoiding sharing of hardware resources with untrusted code when possible. For example, when renting compute resources from cloud providers, select options which explicitly avoid sharing the underlying hardware with other tenants.
If untrusted code is required to run on the system, the effort required for an attack can be increased by removing information about the layout of data in physical memory. For example, disabling the /dev/mem interface and requiring privileges to read /proc/PID/pagemap in a Linux-based system. Disabling allocation of non-cachable memory regions and the use of cache flush instructions from unprivileged software will also increase the effort required for a successful attack. Increasing the DRAM refresh rate (often possible through BIOS settings) is another option to increase the difficulty of the attack, but care must be taken to ensure the attacker cannot also modify the refresh rate or other DRAM operating parameters through the BIOS or other hardware configuration interfaces.
Finally, when designing systems, select DRAM with countermeasures such as Targeted Row Refresh (TRR) and on-die ECC and verify that the countermeasures are enabled (and cannot be disabled by the attacker) in the production system. Even though researchers have successfully performed both RowHammer and RowPress on systems with these countermeasures, their presence increases the complexity of the attacks and decreases their effectiveness.