Row Hammer – A New Profound Threat to Information Security

Row Hammer – A New Profound Threat to Information Security
Every one of us understands the importance of Memory in this digital world, and it has become the prime target of attackers to consider for exploitation from the machine/DB level rather than the application layer. 
One among such threat to memory is Row Hammer, which will directly effect on the machine’s dynamic random-access memory (DRAM). This will cause the memory cells to leak their charges and electrically interact among themselves.  These small geometries put the memory so close together that results in one memory cell’s charge to leak into an adjacent one causing a bit flip.  Very simply the problem occurs when the memory controller under command of the software causes an ACTIVATE command to a single row address repetitively.  If the physically adjacent rows have not been ACTIVATED or refreshed recently the charge from the over ACTIVATED row leaks into the dormant adjacent rows and cause a bit to flip.   This failure mechanism has been coined ‘Row Hammer’ as a row of memory cells are being ‘hammered’ with ACTIVATE commands.  Once this failure occurs a Refresh command from the Memory Controller solidifies the error into the memory cell. So a DRAM read cycle is actually implemented in hardware as a read – and – refresh cycle.
This is made possible because the DRAM cells are being designed and manufactured smaller and integrated close to each other respecting the size constraints. As DRAM manufacturing scales down chip features to smaller physical dimensions, to fit more memory capacity onto a chip, it has become harder to prevent DRAM cells from interacting electrically with each other. As a result, accessing one location in memory can disturb neighboring locations, causing charge to leak into or out of neighboring cells. With enough accesses, this can change a cell’s value from 1 to 0 or vice versa.
Two of such Row Hammer exploits have been recorded recently
  1. Google Zero’s Project
  2. Project Zero
1. Google Zero’s Project
This exploit is targeted towards Privilege escalation based on Row Hammer effect, establishing its exploitable nature on x86-64 architecture. This exploit has resulted in giving the system instructions on machine language and gain complete control over it. This Vulnerability tracked as CVE-2015-0565 with the mitigation for this particular exploit being not to allow execution of cc flush (cache line Flush).
2. Project Zero
This exploit runs as an unprivileged Linux process on x86-64 architecture. This exploit helps to gain access to all the physical memory installed in the computer. This particular exploit will alter the page table entries. Whenever tested for this exploit half of machine was found to be attacked with this particular exploit.
Row Hammer Exploit Mitigation:
The possible mitigations for the Row Hammer exploit:
  1. Two-times (2x) refresh
  2. Pseudo Target Row Refresh
  3. Increased Patrol Scrub timers
1.Two-times (2x) refresh: This is a common form of mitigation implemented on server based chipsets from Intel since the introduction of Sandy Bridge and is considered as a default solution.  This reduces the row refresh time by the memory controller from 64ms to 32ms and shrinks the potential window for a row hammer, or other gate pass type memory error to be introduced.
2.Pseudo Target Row Refresh (pTRR): This particular mitigation is available in modern memory and chipsets. pTRR does not introduce any performance and power impact.
3.Increased Patrol Scrub timers: The systems equipped with ECC memory will often have a BIOS option allowing the administrator to set an interval for the CPU to utilize the checksum data stored on each ECC DIMM module. This will ensure that the contents of memory are valid and ensures a possibility of correcting any bit errors which may have been introduced.  The number of correctable errors will vary based on architecture and ECC variant.  This will help the administrators to reduce the patrol scrub timers from the standard 20-minute interval to a much lower value.


All of the mentioned solutions target the Chip Level or Bios Level using Checksum. However, the issue needs a resolution at route level by using an algorithm to change the allocation of the memory cells internally. This could also be possible through proper validations, using plain javascript and software’s and most importantly ensuring presence & appropriate functionality of IDS/IPS systems. 

Authored By - Sreekanth Gundu
TCS Enterprise Security and Risk Management
Rate this article: 
No votes yet
Article category: