View source for Row hammer

{{Short description|Computer security exploit}}
{{Good article}}
{{Use mdy dates|date=March 2015}}

'''Rowhammer''' (also written as '''row hammer''') is a computer security exploit that takes advantage of an unintended and undesirable side effect in [[dynamic random-access memory]] (DRAM) in which [[memory cell (computing)|memory cells]] interact electrically between themselves by leaking their charges, possibly changing the contents of nearby [[memory row]]s that were not [[memory address|addressed]] in the original memory access. This circumvention of the isolation between DRAM memory cells results from the high cell density in modern DRAM, and can be triggered by specially crafted [[memory access pattern]]s that rapidly activate the same memory rows numerous times.<ref name="isca14-paper">{{cite web
| url = http://users.ece.cmu.edu/~yoonguk/papers/kim-isca14.pdf
| title = Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
| date = June 24, 2014 | access-date = March 10, 2015
| author1 = Yoongu Kim | author2 = Ross Daly | author3 = Jeremie Kim
| author4 = Chris Fallin | author5 = Ji Hye Lee | author6 = Donghyuk Lee
| author7 = Chris Wilkerson | author8 = Konrad Lai | author9 = Onur Mutlu
| publisher = [[IEEE]] | website = ece.cmu.edu
}}</ref><ref name="arstechnica">{{cite web |author=Goodin |first=Dan |date=March 10, 2015 |title=Cutting-edge hack gives super user status by exploiting DRAM weakness |url=https://arstechnica.com/security/2015/03/cutting-edge-hack-gives-super-user-status-by-exploiting-dram-weakness/ |access-date=March 10, 2015 |publisher=[[Ars Technica]]}}</ref><ref name="sophos">{{cite web |author=Ducklin |first=Paul |date=March 12, 2015 |title='Row hammering' – how to exploit a computer by overworking its memory |url=https://nakedsecurity.sophos.com/2015/03/12/row-hammering-how-to-exploit-a-computer-by-overworking-its-memory/ |access-date=March 14, 2015 |publisher=[[Sophos]]}}</ref>

The Rowhammer effect has been used in some [[privilege escalation]] computer security [[exploit (computer security)|exploits]],<ref name="arstechnica"/><ref name="googleprojectzero">{{cite web |last1=Seaborn |first1=Mark |last2=Dullien |first2=Thomas |date=March 9, 2015 |title=Exploiting the DRAM rowhammer bug to gain kernel privileges |url=http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html |access-date=March 10, 2015 |website=googleprojectzero.blogspot.com}}</ref><ref>{{cite news
| url = https://arstechnica.com/security/2016/10/using-rowhammer-bitflips-to-root-android-phones-is-now-a-thing/
| title = Using Rowhammer bitflips to root Android phones is now a thing
| newspaper = Ars Technica
| access-date = October 25, 2016
}}</ref><ref>{{cite news
| url = https://thehackernews.com/2018/05/rowhammer-android-hacking.html
| title = GLitch: New 'Rowhammer' Attack Can Remotely Hijack Android Phones
| author = Swati Khandelwal | work = The Hacker News
| date = May 3, 2018 | access-date = May 21, 2018
}}</ref> and network-based attacks are also theoretically possible.<ref>{{cite news
| url = https://thehackernews.com/2018/05/rowhammer-attack-exploit.html
| title = New Rowhammer Attack Can Hijack Computers Remotely Over the Network
| author = Mohit Kumar | work = The Hacker News
| date = May 10, 2018 | access-date = May 21, 2018
}}</ref><ref>{{cite news
| url = https://thehackernews.com/2018/05/remote-rowhammer-attack.html
| title = Nethammer—Exploiting DRAM Rowhammer Bug Through Network Requests
| author = Swati Khandelwal | work = The Hacker News
| date = May 16, 2018 | access-date = May 21, 2018
}}</ref>

Different hardware-based techniques exist to prevent the Rowhammer effect from occurring, including required support in some [[central processing unit|processors]] and types of DRAM [[memory module]]s.<ref name="intel-d2s2e4">{{cite web
| url = http://infobazy.gda.pl/2014/pliki/prezentacje/d2s2e4-Kaczmarski-Optymalna.pdf
| title = Thoughts on Intel Xeon E5-2600 v2 Product Family Performance Optimisation – Component selection guidelines
| date = August 2014
| access-date = March 11, 2015
| author = Marcin Kaczmarski
| publisher = [[Intel]]
| page = 13
| archive-date = April 18, 2024
| archive-url = https://web.archive.org/web/20240418012923/http://www.infobazy.gda.pl/2014/pliki/prezentacje/d2s2e4-Kaczmarski-Optymalna.pdf
| url-status = dead
}}</ref><ref name="memcon-net105">{{cite web |author=Greenberg |first=Marc |date=October 15, 2014 |title=Reliability, Availability, and Serviceability (RAS) for DDR DRAM interfaces |url=http://www.memcon.com/pdfs/proceedings2014/NET105.pdf |url-status=dead |archive-url=https://web.archive.org/web/20160705220034/http://www.memcon.com/pdfs/proceedings2014/NET105.pdf |archive-date=July 5, 2016 |access-date=March 11, 2015 |website=memcon.com |pages=2, 7, 10, 20, 27}}</ref>

== Background ==
[[File:DRAM.svg|thumb|right|upright=1.4|A high-level illustration of DRAM organization, which includes [[memory cell (computing)|memory cells]] (blue squares), [[address decoder]]s (green rectangles), and [[sense amplifier]]s (red squares)]]

In [[dynamic RAM]] (DRAM), each [[bit]] of stored data occupies a separate memory cell that is electrically implemented with one [[capacitor]] and one [[transistor]]. The charge state of a capacitor (charged or discharged) is what determines whether a DRAM cell stores "1" or "0" as a [[binary value]]. Huge numbers of DRAM memory cells are packed into [[integrated circuit]]s, together with some additional logic that organizes the cells for the purposes of reading, writing, and [[memory refresh|refreshing]] the data.<ref name="cs7810">{{cite web
| url = http://www.eng.utah.edu/~cs7810/pres/11-7810-12.pdf
| title = Lecture 12: DRAM Basics
| date = February 17, 2011 | access-date = March 10, 2015
| website = utah.edu | pages = 2–7
}}</ref><ref name="ece548">{{cite web
| url = https://www.ece.cmu.edu/~ece548/localcpy/dramop.pdf
| title = Understanding DRAM Operation
| date = December 1996
| access-date = March 10, 2015
| publisher = [[IBM]]
| archive-url = https://web.archive.org/web/20170829153054/http://www.ece.cmu.edu/~ece548/localcpy/dramop.pdf
| archive-date = August 29, 2017
| url-status = dead
}}</ref>

Memory cells (blue squares in both illustrations) are further organized into [[matrix (mathematics)|matrices]] and addressed through rows and columns. A memory address applied to a matrix is broken into the row address and column address, which are processed by the row and column [[address decoder]]s (in both illustrations, vertical and horizontal green rectangles, respectively). After a row address selects the row for a read operation (the selection is also known as [[row activation]]), bits from all cells in the row are transferred into the [[sense amplifier]]s that form the row buffer (red squares in both illustrations), from which the exact bit is selected using the column address. Consequently, read operations are of a destructive nature because the design of DRAM requires memory cells to be rewritten after their values have been read by transferring the cell charges into the row buffer. Write operations decode the addresses in a similar way, but as a result of the design entire rows must be rewritten for the value of a single bit to be changed.<ref name="isca14-paper"/>{{rp|2–3}}<ref name="cs7810"/><ref name="ece548"/><ref>{{cite web
| url = https://www.cs.princeton.edu/courses/archive/fall04/cos471/lectures/20-Memory.pdf
| archive-url = https://web.archive.org/web/20050519185856/http://www.cs.princeton.edu/courses/archive/fall04/cos471/lectures/20-Memory.pdf
| title = Lecture 20: Memory Technology
| date = November 23, 2004 | access-date = March 10, 2015
| archive-date = May 19, 2005
| author = David August | website = cs.princeton.edu
| pages = 3–5
}}</ref>

As a result of storing data bits using capacitors that have a natural discharge rate, DRAM memory cells lose their state over time and require periodic [[memory refresh|rewriting]] of all memory cells, which is a process known as refreshing.<ref name="isca14-paper"/>{{rp|3}}<ref name="cs7810"/> As another result of the design, DRAM memory is susceptible to random changes in stored data, which are known as [[soft error|soft memory errors]] and attributed to [[cosmic ray#Effect on electronics|cosmic rays]] and other causes. There are different techniques that counteract soft memory errors and improve the reliability of DRAM, of which [[ECC memory|error-correcting code (ECC) memory]] and its advanced variants (such as [[lockstep memory]]) are most commonly used.<ref>{{cite web
| url = http://www.cs.toronto.edu/~bianca/papers/sigmetrics09.pdf
| title = DRAM Errors in the Wild: A Large-Scale Field Study
| date = June 25, 2009 | access-date = March 10, 2015
| author1 = Bianca Schroeder |author1-link= Bianca Schroeder | author2 = Eduardo Pinheiro | author3 = Wolf-Dietrich Weber
| publisher = [[Association for Computing Machinery|ACM]]
| website = cs.toronto.edu
}}</ref>

== {{Anchor|DISTURBANCE|VICTIM|DOUBLE}}Overview ==
[[File:Row hammer.svg|thumb|right|upright=1.4|Rapid row activations (yellow rows) may change the values of bits stored in victim row (purple row).<ref name="isca14-talk"/>{{rp|2}}]]

Increased densities of [[dynamic random-access memory|DRAM]] [[integrated circuit]]s have led to physically smaller memory cells containing less charge, resulting in lower operational [[noise margin]]s, increased rates of electromagnetic interactions between memory cells, and greater possibility of data loss. As a result, ''disturbance errors'' have been observed, being caused by cells interfering with each other's operation and manifesting as random changes in the values of bits stored in affected memory cells. The awareness of disturbance errors dates back to the early 1970s and [[Intel&nbsp;1103]] as the first commercially available DRAM integrated circuits; since then, DRAM manufacturers have employed various [[vulnerability mitigation|mitigation]] techniques to counteract disturbance errors, such as improving the isolation between cells and performing production testing. However, researchers proved in a 2014 analysis that commercially available [[DDR3 SDRAM]] chips manufactured in 2012 and 2013 are susceptible to disturbance errors, while using the term ''Rowhammer'' to name the associated side effect that led to observed [[soft error|bit flips]].<ref name="isca14-paper"/><ref name="sophos"/><ref name="isca14-talk">{{cite web
| url = http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf
| title = Flipping Bits in Memory Without Accessing Them: DRAM Disturbance Errors
| date = June 24, 2014 | access-date = March 10, 2015
| author1 = Yoongu Kim | author2 = Ross Daly | author3 = Jeremie Kim
| author4 = Chris Fallin | author5 = Ji Hye Lee | author6 = Donghyuk Lee
| author7 = Chris Wilkerson | author8 = Konrad Lai | author9 = Onur Mutlu
| website = ece.cmu.edu
}}</ref>

The opportunity for the Rowhammer effect to occur in DDR3 memory<ref name="kyungbae">{{cite book
| title = Active-Precharge Hammering on a Row Induced Failure in DDR3 SDRAMs under 3x&nbsp;nm Technology
| pages = 82–85
| date = October 2014 | author1 = Kyungbae Park | author2 = Sanghyeon Baeg
| author3 = ShiJie Wen | author4 = Richard Wong
| publisher = [[IEEE]]
| doi = 10.1109/IIRW.2014.7049516
| chapter = Active-precharge hammering on a row induced failure in DDR3 SDRAMs under 3× nm technology
| isbn = 978-1-4799-7308-8
| s2cid = 14464953
}}</ref> is primarily attributed to DDR3's high density of memory cells and the results of associated interactions between the cells, while rapid DRAM row activations have been determined as the primary cause. Frequent row activations cause [[voltage]] fluctuations on the associated row selection lines, which have been observed to induce higher-than-natural discharge rates in capacitors belonging to nearby (adjacent, in most cases) memory rows, which are called ''victim rows''; if the affected memory cells are not [[memory refresh|refreshed]] before they lose too much charge, disturbance errors occur. Tests show that a disturbance error may be observed after performing around 139,000 subsequent memory row accesses (with [[cache flush]]es), and that up to one memory cell in every 1,700 cells may be susceptible. Those tests also show that the rate of disturbance errors is not substantially affected by increased environment temperature, while it depends on the actual contents of DRAM because certain [[bit pattern]]s result in significantly higher disturbance error rates.<ref name="isca14-paper"/><ref name="arstechnica"/><ref name="isca14-talk"/><ref>{{cite web
| url = http://users.ece.cmu.edu/~omutlu/pub/rowhammer-summary.pdf
| title = RowHammer: Reliability Analysis and Security Implications
| date = July 30, 2015 | access-date = August 7, 2015
| author1 = Yoongu Kim | author2 = Ross Daly | author3 = Jeremie Kim
| author4 = Chris Fallin | author5 = Ji Hye Lee | author6 = Donghyuk Lee
| author7 = Chris Wilkerson | author8 = Konrad Lai | author9 = Onur Mutlu
| website = ece.cmu.edu
}}</ref>

A variant called ''double-sided hammering'' involves targeted activations of two DRAM rows surrounding a victim row: in the illustration provided in this section, this variant would be activating both yellow rows with the aim of inducing bit flips in the purple row, which in this case would be the victim row. Tests show that this approach may result in a significantly higher rate of disturbance errors, compared to the variant that activates only one of the victim row's neighboring DRAM rows.<ref name="googleprojectzero"/><ref name="blackhat">{{cite web
| url = https://www.blackhat.com/docs/us-15/materials/us-15-Seaborn-Exploiting-The-DRAM-Rowhammer-Bug-To-Gain-Kernel-Privileges.pdf
| title = Exploiting the DRAM rowhammer bug to gain kernel privileges: How to cause and exploit single bit errors
| date = August 6, 2015 | access-date = August 7, 2015
| author1 = Mark Seaborn | author2 = Thomas Dullien
| publisher = [[Black Hat Briefings|Black Hat]]
}}</ref>{{rp|19–20}}<ref>{{cite magazine
| url = https://www.wired.com/2015/03/google-hack-dram-memory-electric-leaks/
| title = Googlers' Epic Hack Exploits How Memory Leaks Electricity
| magazine = Wired
| date = March 10, 2015 | access-date = March 17, 2015
| author = Andy Greenberg
}}</ref>

As DRAM vendors have deployed mitigations, patterns had to become more sophisticated to bypass Rowhammer mitigations. More recent Rowhammer patterns include non-uniform, frequency-based patterns.<ref name=":0" /> These patterns consist of many double-sided aggressors pairs where each of them is hammered with a different frequency, phase, and amplitude. Using this and synchronizing patterns with the REFRESH command, it is possible to very effectively determine "blind spots" where the mitigation is not able to provide protection anymore. Based on this idea, academics built a Rowhammer fuzzer named ''Blacksmith''<ref>{{Citation |title=Blacksmith Rowhammer Fuzzer |date=2022-11-02 |url=https://github.com/comsec-group/blacksmith |access-date=2022-11-09}}</ref> that can bypass existing mitigations on all DDR4 devices.

=== {{Anchor|MAC|MAW|TEST|TRR}}Mitigation ===
Different methods exist for more or less successful detection, prevention, correction or mitigation of the Rowhammer effect. Tests show that simple [[ECC memory|error correction code]], providing [[single-error correction and double-error detection]] (SECDED) capabilities, are not able to correct or detect all observed disturbance errors because some of them include more than two flipped bits per [[memory word]].<ref name="isca14-paper"/>{{rp|8}}<ref name="isca14-talk"/>{{rp|32}} Furthermore, research shows that precisely targeted three-bit Rowhammer flips prevents ECC memory from noticing the modifications.<ref>{{cite conference | doi = 10.1109/sp.2019.00089
| last1 = Cojocar | first1 = Lucian | last2 = Razavi | first2 = Kaveh | last3 = Giuffrida | first3 = Cristiano | last4 = Bos | first4 = Herbert
| title = 2019 IEEE Symposium on Security and Privacy (SP) | chapter = Exploiting Correcting Codes: On the Effectiveness of ECC Memory Against Rowhammer Attacks
| publisher = IEEE | year = 2019 | pages = 55–71 | isbn = 978-1-5386-6660-9 | conference = Symposium on Security & Privacy
| chapter-url = https://download.vusec.net/papers/eccploit_sp19.pdf | access-date=2022-05-30
| doi-access = free }}</ref><ref>{{cite web | url = https://www.vusec.net/projects/eccploit/
| title = ECCploit: ECC Memory Vulnerable to Rowhammer Attacks After All
| publisher = [[Vrije Universiteit Amsterdam]] | author = VUsec, Systems and Network Security Group
| date = November 11, 2018 | access-date = 2022-05-30
}}</ref>

A less effective solution is to introduce more frequent memory refreshing, with the [[memory refresh interval|refresh intervals]] shorter than the usual 64&nbsp;ms,{{Efn|Research shows that the rate of disturbance errors in a selection of [[DDR3]] memory modules closes to zero when the [[memory refresh interval]] becomes roughly seven times shorter than the default of 64&nbsp;ms.<ref name="isca14-talk"/>{{rp|17,26}}}} but this technique results in higher power consumption and increased processing overhead; some vendors provide [[firmware]] updates that implement this type of mitigation.<ref>{{cite web
| url = https://support.lenovo.com/us/en/product_security/row_hammer
| title = Row Hammer Privilege Escalation (Lenovo Security Advisory LEN-2015-009)
| date = August 5, 2015 | access-date = August 6, 2015
| publisher = [[Lenovo]]
}}</ref> One of the more complex prevention measures performs [[counter (digital)|counter]]-based identification of frequently accessed memory rows and proactively refreshes their neighboring rows; another method issues additional infrequent random refreshes of memory rows neighboring the accessed rows regardless of their access frequency. Research shows that these two prevention measures cause negligible performance impacts.<ref name="isca14-paper"/>{{rp|10–11}}<ref>{{cite web
 |url         = http://users.ece.gatech.edu/~pnair6/rowhammer/rowhammer.pdf
 |title       = Architectural Support for Mitigating Row Hammering in DRAM Memories
 |date        = October 9, 2014
 |access-date  = March 11, 2015
 |author1     = Dae-Hyun Kim
 |author2     = Prashant J. Nair
 |author3     = Moinuddin K. Qureshi
 |publisher   = [[IEEE]]
 |website     = ece.gatech.edu
 |url-status     = dead
 |archive-url  = https://web.archive.org/web/20150311061310/http://users.ece.gatech.edu/~pnair6/rowhammer/rowhammer.pdf
 |archive-date = March 11, 2015
 |df          = mdy-all
}}</ref>

Since the release of [[Ivy Bridge (microarchitecture)|Ivy Bridge]] [[microarchitecture]], [[Intel]] [[Xeon]] processors support the so-called ''pseudo target row refresh'' (pTRR) that can be used in combination with pTRR-compliant DDR3 [[dual in-line memory module]]s (DIMMs) to mitigate the Rowhammer effect by automatically refreshing possible victim rows, with no negative impact on performance or power consumption. When used with DIMMs that are not pTRR-compliant, these Xeon processors by default fall back on performing DRAM refreshes at twice the usual frequency, which results in slightly higher memory access latency and may reduce the memory bandwidth by up to 2–4%.<ref name="intel-d2s2e4"/>

The [[LPDDR4]] mobile memory standard published by [[JEDEC]]<ref name="jedec-lpddr4">{{cite web
| url = http://www.jedec.org/standards-documents/docs/jesd209-4a
| title = JEDEC standard JESD209-4A: Low Power Double Data Rate (LPDDR4)
| date = November 2015 | access-date = January 10, 2016
| publisher = [[JEDEC]] | format = PDF
| pages = 222–223
}}</ref> includes optional hardware support for the so-called ''target row refresh'' (TRR) that prevents the Rowhammer effect without negatively impacting performance or power consumption.<ref name="memcon-net105"/><ref>{{cite web
| url = http://www.memcon.com/pdfs/proceedings2014/MOB102.pdf#page=11
| title = DRAM scaling challenges and solutions in LPDDR4 context
| date = October 22, 2014
| access-date = January 10, 2016
| author = Kishore Kasamsetty
| website = memcon.com
| format = PDF
| page = 11
| archive-url = https://web.archive.org/web/20160603103733/http://www.memcon.com/pdfs/proceedings2014/MOB102.pdf#page=11
| archive-date = June 3, 2016
| url-status = dead
}}</ref><ref>{{cite web
| url = http://blogs.cisco.com/security/mitigations-available-for-the-dram-row-hammer-vulnerability
| title = Mitigations Available for the DRAM Row Hammer Vulnerability
| date = March 9, 2015 | access-date = March 11, 2015
| author = Omar Santos | website = cisco.com
}}</ref> Additionally, some manufacturers implement TRR in their [[DDR4]] products,<ref>{{cite web
| url = https://blogs.synopsys.com/committedtomemory/2015/03/09/row-hammering-what-it-is-and-how-hackers-could-use-it-to-gain-access-to-your-system/
| title = Row Hammering: What it is, and how hackers could use it to gain access to your system
| date = March 9, 2015 | access-date = January 10, 2016
| author = Marc Greenber | website = synopsys.com
}}</ref><ref>{{cite web
| url = http://aod.teletogether.com/sec/20140519/SAMSUNG_Investors_Forum_2014_session_1.pdf#page=15
| title = Green Memory Solution (Samsung Investors Forum 2014)
| date = November 7, 2014 | access-date = January 10, 2016
| author = Jung-Bae Lee | publisher = [[Samsung Electronics]]
| website = teletogether.com | format = PDF | page = 15
}}</ref> although it is not part of the DDR4 memory standard published by JEDEC.<ref>{{cite web
| url = https://www.jedec.org/standards-documents/docs/jesd79-4a
| title = JEDEC standard JESD79-4A: DDR4 SDRAM
| date = November 2013 | access-date = January 10, 2016
| publisher = [[JEDEC]] | format = PDF
}}</ref> Internally, TRR identifies possible victim rows, by counting the number of row activations and comparing it against predefined [[integrated circuit|chip]]-specific ''maximum activate count'' (MAC) and ''maximum activate window'' (t<sub>MAW</sub>) values, and refreshes these rows to prevent bit flips. The MAC value is the maximum total number of row activations that may be encountered on a particular DRAM row within a time interval that is equal or shorter than the t<sub>MAW</sub> amount of time before its neighboring rows are identified as victim rows; TRR may also flag a row as a victim row if the sum of row activations for its two neighboring rows reaches the MAC limit within the t<sub>MAW</sub> time window.<ref name="jedec-lpddr4"/><ref>{{cite web
| url = http://www.micron.com/~/media/documents/products/data-sheet/dram/ddr4/4gb_ddr4_sdram.pdf
| title = Data Sheet: 4&nbsp;Gb ×4, ×8 and ×16 DDR4 SDRAM Features
| date = November 20, 2015
| access-date = January 10, 2016
| publisher = [[Micron Technology]]
| pages = 48, 131
| archive-url = https://web.archive.org/web/20180210062029/https://www.micron.com/~/media/documents/products/data-sheet/dram/ddr4/4gb_ddr4_sdram.pdf
| archive-date = February 10, 2018
| url-status = dead
}}</ref> Research showed that TRR mitigations deployed on DDR4 UDIMMs and LPDDR4X chips from devices produced between 2019 and 2020 are not effective in protecting against Rowhammer.<ref name=":0">{{cite web |last1=Jattke |first1=Patrick |last2=van der Veen |first2=Victor |last3=Frigo |first3=Pietro |last4=Gunter |first4=Stijn |last5=Razavi |first5=Kaveh |date=May 25, 2022 |title=Blacksmith: Scalable Rowhammering in the Frequency Domain |url=https://comsec.ethz.ch/wp-content/files/blacksmith_sp22.pdf |access-date=November 9, 2022 |website=comsec.ethz.ch |publisher=[[IEEE]]}}</ref>

Due to their necessity of huge numbers of rapidly performed DRAM row activations, Rowhammer exploits issue large numbers of uncached memory accesses that cause [[cache miss]]es, which can be detected by monitoring the rate of cache misses for unusual peaks using [[hardware performance counter]]s.<ref name="googleprojectzero"/><ref>{{cite web
| url = https://www.blackhat.com/docs/us-15/materials/us-15-Herath-These-Are-Not-Your-Grand-Daddys-CPU-Performance-Counters-CPU-Hardware-Performance-Counters-For-Security.pdf
| title = These are Not Your Grand Daddy's CPU Performance Counters: CPU Hardware Performance Counters for Security
| date = August 6, 2015 | access-date = January 9, 2016
| author1 = Nishad Herath | author2 = Anders Fogh
| publisher = [[Black Hat Briefings|Black Hat]] | pages = 29, 38–68
}}</ref>

Version 5.0 of the [[MemTest86]] memory diagnostic software, released on December 3, 2013, added a Rowhammer test that checks whether computer RAM is susceptible to disturbance errors, but it only works if the computer boots [[UEFI]]; without UEFI, it boots an older version with no hammer test.<ref>{{cite web
| url = https://www.memtest86.com/support/ver_history.htm
| title = PassMark MemTest86 – Version History
| date = February 13, 2015 | access-date = March 11, 2015
| website = memtest86.com
}}</ref>

== Implications ==
[[Memory protection]], as a way of preventing [[process (computing)|processes]] from accessing memory that has not been [[Memory management|assigned]] to each of them, is one of the concepts behind most modern [[operating system]]s. By using memory protection in combination with other security-related mechanisms such as [[protection ring]]s, it is possible to achieve [[privilege separation]] between processes, in which [[computer program|programs]] and computer systems in general are divided into parts limited to the specific [[privilege (computing)|privileges]] they require to perform a particular task. Using privilege separation can also reduce the extent of potential damage caused by [[computer security]] attacks by restricting their effects to specific parts of the system.<ref>{{cite web
| url = http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasakh10/Slides/dasakh10Lecture09memory.pdf
| title = Memory Protection
| year = 2011
| access-date = March 11, 2015
| author = Pehr Söderman
| website = csc.kth.se
| archive-date = April 2, 2015
| archive-url = https://web.archive.org/web/20150402171128/http://www.csc.kth.se/utbildning/kth/kurser/DD2395/dasakh10/Slides/dasakh10Lecture09memory.pdf
| url-status = dead
}}</ref><ref>{{cite web
| url = http://niels.xtdnet.nl/papers/privsep.pdf
| title = Preventing Privilege Escalation
| date = August 10, 2003 | access-date = March 11, 2015
| author1 = Niels Provos | author2 = Markus Friedl | author3 = Peter Honeyman
| website = niels.xtdnet.nl
}}</ref>

Disturbance errors (explained in the [[#DISTURBANCE|section above]]) effectively defeat various layers of memory protection by "[[short circuit]]ing" them at a very low hardware level, practically creating a unique [[attack vector]] type that allows processes to alter the contents of arbitrary parts of the [[main memory]] by directly manipulating the underlying memory hardware.<ref name="arstechnica"/><ref name="googleprojectzero"/><ref name="blackhat"/><ref name="zdnet">{{cite web
| url = https://www.zdnet.com/article/rowhammer-dram-flaw-could-be-widespread-says-google/
| title = "Rowhammer" DRAM flaw could be widespread, says Google
| date = March 10, 2015 | access-date = March 11, 2015
| author = Liam Tung | publisher = [[ZDNet]]
}}</ref> In comparison, "conventional" attack vectors such as [[buffer overflow]]s aim at circumventing the protection mechanisms at the software level, by [[exploit (computer security)|exploiting]] various programming mistakes to achieve alterations of otherwise inaccessible main memory contents.<ref>{{cite web
| url = http://www.enderunix.org/docs/en/bof-eng.txt
| title = Buffer Overflows Demystified
| date = June 6, 2009 | access-date = March 11, 2015
| author = Murat Balaban | website = enderunix.org
| format = TXT
}}</ref>

=== {{Anchor|JS}}Exploits ===
{| class="wikitable floatright" style="margin-left: 1.5em; margin-top: 0.5em; width: 29em;"
|-
| class="nowrap" |
<syntaxhighlight lang="asm">
hammer:
  mov (X), %eax  // read from address X
  mov (Y), %ebx  // read from address Y
  clflush (X)    // flush cache for address X
  clflush (Y)    // flush cache for address Y
  jmp hammer
</syntaxhighlight>
|-
| style="font-size: 90%; padding-left: 7px; padding-right: 7px;" | A snippet of [[x86 assembly language|x86 assembly]] code that induces the row hammer effect (memory addresses <code>X</code> and <code>Y</code> must map to different DRAM rows in the same [[memory bank]])<ref name="isca14-paper"/>{{rp|3}}<ref name="googleprojectzero"/><ref name="blackhat"/>{{rp|13–15}}
|}

The initial research into the Rowhammer effect, published in June 2014, described the nature of disturbance errors and indicated the potential for constructing an attack, but did not provide any examples of a working security exploit.<ref name="isca14-paper"/> A subsequent October 2014 research paper did not imply the existence of any security-related issues arising from the Rowhammer effect.<ref name="kyungbae"/>

On March 9, 2015, [[Google]]'s [[Project Zero]] revealed two working [[privilege escalation]] exploits based on the Rowhammer effect, establishing its exploitable nature on the [[x86-64]] architecture. One of the revealed exploits targets the [[Google Native Client]] (NaCl) mechanism for running a limited subset of x86-64 [[machine instruction]]s within a [[sandbox (computer security)|sandbox]],<ref name="blackhat"/>{{rp|27}} exploiting the Rowhammer effect to escape from the sandbox and gain the ability to issue [[system call]]s directly. This NaCl [[Vulnerability (computing)|vulnerability]], tracked as {{CVE|2015-0565}}, has been mitigated by modifying the NaCl so it does not allow execution of the <code>clflush</code> ([[cache line]] flush<ref>{{cite web
| url = http://x86.renejeschke.de/html/file_module_x86_id_30.html
| title = CLFLUSH: Flush Cache Line (x86 Instruction Set Reference)
| date = March 3, 2013
| access-date = August 6, 2015
| website = renejeschke.de
| archive-url = https://web.archive.org/web/20171203034552/http://x86.renejeschke.de/html/file_module_x86_id_30.html
| archive-date = December 3, 2017
| url-status = dead
}}</ref>) machine instruction, which was previously believed to be required for constructing an effective Rowhammer attack.<ref name="arstechnica"/><ref name="googleprojectzero"/><ref name="zdnet"/>

The second exploit revealed by Project Zero runs as an unprivileged [[Linux]] process on the x86-64 architecture, exploiting the Rowhammer effect to gain unrestricted access to all [[physical memory]] installed in a computer. By combining the disturbance errors with [[memory spraying]], this exploit is capable of altering [[page table entry|page table entries]]<ref name="blackhat"/>{{rp|35}} used by the [[virtual memory]] system for mapping [[virtual address]]es to [[physical address]]es, which results in the exploit gaining unrestricted memory access.<ref name="blackhat"/>{{rp|34,36–57}} Due to its nature and the inability of the x86-64 architecture to make <code>clflush</code> a privileged machine instruction, this exploit can hardly be mitigated on computers that do not use hardware with built-in Rowhammer prevention mechanisms. While testing the viability of exploits, Project Zero found that about half of the 29 tested [[laptop]]s experienced disturbance errors, with some of them occurring on vulnerable laptops in less than five minutes of running row-hammer-inducing code; the tested laptops were manufactured between 2010 and 2014 and used non-ECC DDR3 memory.<ref name="arstechnica"/><ref name="googleprojectzero"/><ref name="zdnet"/>

In July 2015, a group of security researchers published a paper that describes an [[computer architecture|architecture]]- and [[instruction set|instruction-set]]-independent way for exploiting the Rowhammer effect. Instead of relying on the <code>clflush</code> instruction to perform cache flushes, this approach achieves uncached memory accesses by causing a very high rate of [[cache eviction]] using carefully selected memory access patterns. Although the [[cache replacement policy|cache replacement policies]] differ between processors, this approach overcomes the architectural differences by employing an adaptive cache eviction strategy [[algorithm]].<ref name="blackhat"/>{{rp|64–68}} The [[proof of concept]] for this approach is provided both as a [[native code]] implementation, and as a pure [[JavaScript]] implementation that runs on [[Firefox]]&nbsp;39. The JavaScript implementation, called ''Rowhammer.js'',<ref>{{cite web
| url = https://github.com/IAIK/rowhammerjs/blob/master/javascript/rowhammer.js
| title = IAIK/rowhammerjs: rowhammerjs/rowhammer.js at master
| date = July 27, 2015 | access-date = July 29, 2015
| author1 = Daniel Gruss | author2 = Clémentine Maurice
| website = github.com
}}</ref> uses large [[strong and weak typing|typed]] [[array data structure|arrays]] and relies on their internal [[memory allocation|allocation]] using [[large page]]s; as a result, it demonstrates a very high-level exploit of a very low-level vulnerability.<ref>{{cite arXiv
| eprint = 1507.06955
| title = Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript
| date = July 24, 2015
| author1 = Daniel Gruss | author2 = Clementine Maurice | author3 = Stefan Mengard
| class = cs.CR
}}</ref><ref>{{cite web
| url = http://www.slate.com/articles/technology/bitwise/2015/07/rowhammer_security_exploit_why_a_new_security_attack_is_truly_terrifying.html
| title = Rowhammer security exploit: Why a new security attack is truly terrifying
| date = July 28, 2015 | access-date = July 29, 2015
| author = David Auerbach | website = slate.com
}}</ref><ref>{{cite news
| url = https://motherboard.vice.com/en_us/article/9akpwz/rowhammerjs-is-the-most-ingenious-hack-ive-ever-seen
| title = Rowhammer.js Is the Most Ingenious Hack I've Ever Seen
| date = July 30, 2015
| author = Alix Jean-Pharuns | publisher = Motherboard
}}</ref><ref>{{cite news
| url = https://arstechnica.com/information-technology/2015/08/dram-bitflipping-exploit-for-attacking-pcs-just-add-javascript/
| title = DRAM 'Bitflipping' exploit for attacking PCs: Just add JavaScript
| author = Dan Goodin | publisher = Ars Technica
| date = August 4, 2015
}}</ref>

In October 2016, researchers published DRAMMER, an Android application that uses Rowhammer, together with other methods, to reliably gain root access on several popular smartphones.<ref>{{cite web
| url = https://www.vusec.net/projects/drammer/
| title = DRAMMER: FLIP FENG SHUI GOES MOBILE
| date = October 2016 | access-date = January 21, 2017
| author = VUSec
}}</ref> The vulnerability was acknowledged as {{CVE|2016-6728}}<ref>{{cite web
| url = https://nvd.nist.gov/vuln/detail/CVE-2016-6728
| title = CVE-2016-6728 Detail
| author = NIST National Vulnerability Database (NVD)
}}</ref> and a mitigation was released by Google within a month.  However, due to the general nature of possible implementations of the attack, an effective software patch is difficult to be reliably implemented. As of June 2018, most patch proposals made by academia and industry were either impractical to deploy or insufficient in stopping all attacks. As a mitigation, researchers proposed a lightweight defense that prevents attacks based on [[direct memory access]] (DMA) by isolating DMA buffers with guard rows.<ref>{{citation
| url = https://research.vu.nl/en/publications/112a5465-aeb5-40fd-98ff-6f3b7c976676
| doi = 10.1007/978-3-319-93411-2_5 | isbn = 9783319934105
| hdl = 1871.1/112a5465-aeb5-40fd-98ff-6f3b7c976676
| title = GuardION: Practical Mitigation of DMA-Based Rowhammer Attacks on ARM
| work = Detection of Intrusions and Malware, and Vulnerability Assessment
| author1 = Victor van der Veen | author2 = Martina Lindorfer
| author3 = Yanick Fratantonio | author4 = Harikrishnan Padmanabha Pillai
| author5 = Giovanni Vigna | author6 = Christopher Kruegel
| author7 = Herbert Bos | author8 = Kaveh Razavi
| publisher = Springer International Publishing
| year = 2018 | pages = 92–113
| hdl-access = free
}}</ref><ref>{{cite web
| url = https://rampageattack.com/
| title = RAMPAGE AND GUARDION - Vulnerabilities in modern phones enable unauthorized access
| access-date = June 30, 2018
}}</ref>

In May 2021, a Google research team announced a new exploit, Half-Double that takes advantage of the worsening physics of some of the newer DRAM chips.<ref>{{cite web|url=https://security.googleblog.com/2021/05/introducing-half-double-new-hammering.html|date=2021-05-25|title=Introducing Half-Double: New hammering technique for DRAM Rowhammer bug|access-date=2021-12-02|publisher=Google}}</ref>

In March 2024, a group of researchers at [[ETH Zürich]] announced ZenHammer, a rowhammer exploit for [[AMD Zen]] chips, and also announced the first use of rowhammer to exploit [[DDR5 SDRAM]].<ref>{{Cite web |title=New ZenHammer memory attack impacts AMD Zen CPUs|first=Bill |last=Toulas |url=https://www.bleepingcomputer.com/news/security/new-zenhammer-memory-attack-impacts-amd-zen-cpus/ |access-date=2024-03-26 |website=BleepingComputer |language=en-us}}</ref><ref>{{Cite web |title=ZenHammer: Rowhammer Attacks on AMD Zen-based Platforms |url=https://comsec.ethz.ch/research/dram/zenhammer/ |access-date=2024-03-26 |website=Computer Security Group |language=en-US}}</ref>

In June 2024, a group of researchers at [[ETH Zürich]] announced RISC-H, a rowhammer exploit for [[RISC-V]] chips, this is the first Rowhammer study on RISC-V.<ref>{{Cite web |title=Rowhammer Bit Flips On A High-End RISC-V CPU (ETH Zurich)|url=https://semiengineering.com/rowhammer-bit-flips-on-a-high-end-risc-v-cpu-eth-zurich/ |access-date=2024-06-15 |website=semiengineering |date=June 13, 2024 |language=en-us}}</ref>

== See also ==
{{Portal|Electronics}}
* [[Memory scrambling]]{{snd}} memory controller feature that turns user data written to the memory into pseudo-random patterns
* [[Radiation hardening]]{{snd}} the act of making electronic components resistant to damage or malfunctions caused by ionizing radiation
* [[Single event upset]] {{snd}} a change of state caused by ions or electromagnetic radiation striking a sensitive node in an electronic device
* [[Soft error]]{{snd}} a type of error involving erroneous changes to signals or data but no changes to the underlying device or circuit

== Notes ==
{{Notelist}}

== References ==
{{Reflist|30em}}

== External links ==
* [http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html Some notes on DRAM (#rowhammer)], March 9, 2015, by Robert Graham
* [http://www.infoworld.com/article/2894497/security/rowhammer-hardware-bug-threatens-to-smash-notebook-security.html Rowhammer hardware bug threatens to smash notebook security], <code>InfoWorld</code>, March 9, 2015, by Serdar Yegulalp
* {{YouTube|id=7wIUQ04Vkes|title=DDR3 Memory Known Failure Mechanism called "Row Hammer"}}, July 17, 2014, by Barbara Aichinger
* [https://patents.google.com/patent/US20140059287 Patent US 20140059287 A1: Row hammer refresh command], February 27, 2014, by Kuljit Bains et al.
* Row Hammer Privilege Escalation Vulnerability, [[Cisco Systems]] security advisory, March 11, 2015
* ARMOR: A run-time memory hot-row detector, [[The University of Manchester]], by Mohsen Ghasempour et al.
* [https://www.cs.princeton.edu/~appel/papers/memerr.pdf Using Memory Errors to Attack a Virtual Machine], March 6, 2003, by Sudhakar Govindavajhala and Andrew W. Appel
* [https://github.com/google/rowhammer-test A program for testing for the DRAM "rowhammer" problem], source code on [[GitHub]]

{{DRAM}}
{{Operating system}}

[[Category:Computer memory]]
[[Category:Computer security exploits]]
[[Category:Data quality]]
[[Category:Privilege escalation exploits]]
[[Category:Denial-of-service attacks]]
[[Category:Hardware bugs]]
[[Category:2014 in computing]]