RowHammer & Attack Surface

Following previous post related to RowHammer JS, following is a discussion on attack surface. I completed these notes as part of work in University of Oxford and towards GCHQ accreditation. All comments are my own.


Discuss the attack in terms of changes in the attack surface between design and implementation, What was additionally introduced and to what extent could this have been visible in the design phase ?


Depending on perspective and contexts a number of relevant elements have been introduced, changed and adopted since their initial design, all of these coupled together have allowed remote rowHammering via JavaScript. DRAM cell density, row buffer cache, CPU cache (L1, L2 and L3), JavaScript widespread adoption, JavaScript increase performance allowing a new adaptive cache eviction algorithm to be designed.

In relation to DRAM, revisiting the diagram from part one you can envisage physical area concerns if you increase the number of cells per row without increasing the actual physical area i.e. density increase (I am not suggesting increase physical area). DRAM cells have scaled significantly in recent years, leading to an increase in cell density i.e. cells are packed closer together. This increase in density of cells and capacitors has impacted isolation of these cells. As [1] outlined it is now possible to flip bits without actually accessing these cells directly, [2] provided more than one exploit while [3] introduced the ability to flip bits via JavaScript and without the need to access the host computer directly. Isolation of these cells is paramount to secure systems i.e. when accessing one row neighboring rows should not be adversely affected, if isolation is vulnerable, and cells are disturbed prior to a refresh a disturbance error occurs. The root cause of row hammer would appear to relate to this increase in cell density, though originally, reliability was seen as the issue as noted by [4] in their most recent presentation on the rowHammer.js paper. In the context of DRAM density it would be reasonable to expect this to have been visible during design as well as implementation i.e. an increase in physical density would have an affect on neighboring physical components such as cells.

With respect to CPU cache L1, L2 and L3 (intel specific in the context of this paper); the design of such cache is mainly focused on performance, in the context of this paper authors where able to leverage L3's inclusive cache design principle that included L1 and L2's data; in addition to L3 being shared among all core's, net result is when L3 is purged L1 and L2 are also purged for the relevant core thus making it 'easier' (used lightly) to invoke a cache miss. In this context of CPU cache, it would have been more difficult or at least less visible at both design and implementation phase for row hammering to be visible during the design. In the context of this paper, cache was used from an observation perspective i.e. a timing attack; by monitoring timings for row access it was possible to determine a cache hit v's a cache miss. A cache hit vs a cache miss tends to leak information, in this case the information leaked is whether an address is cached or not, it can be quiet challenging to determine such a cache hit v's cache miss, however if you have enough samples a pattern emerges. Though as noted by [1], vendors have been aware of row hammering concerns since at least 2012.

In the context of JavaScript (more precisely ECMAScript), two areas are relevant to this paper; JavaScript’s adoption and JavaScript performance. Widespread adoption of JavaScript; as JavaScript is the only native client web browser programming language, where native refers to no additional web browser plugins required. Web applications have become more dynamic, more feature rich, and more reliant on JavaScript especially with introduction of AJAX; thus leading to a requirement for web browser vendors to ensure JavaScript engines to more performant.


[1] Yoongu Kim Ross Daly Jeremie Kim Chris Fallin Ji Hye Lee Donghyuk Lee Chris Wilkerson Konrad Lai Onur Mutlu, Carnegie Mellon & Intel Labs Flipping Bits in Memory Without Accessing Them: An Experimental Study of DRAM Disturbance Errors
https://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_isca14.pdf

[2] Seaborn & Dullien http://googleprojectzero.blogspot.ie/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

[3] Daniel Gruss, Clementine Maurice, Stefan Mangard Rowhammer.js: A Remote Software-Induced Fault Attack in JavaScript
http://arxiv.org/abs/1507.06955

[4] Maurice & Gruss rowHammer.js presentation https://media.ccc.de/v/32c3-7197-rowhammerjsrootprivilegesforwebapps#video&t=1173