You are on page 1of 8

arXiv:1507.06955v1 [cs.

CR] 24 Jul 2015

Rowhammer.js: A Remote Software-Induced Fault
Attack in JavaScript
Daniel Gruss

Cl´ementine Maurice

Stefan Mangard

Graz University of Technology, Austria

Technicolor, Rennes, France
Eurecom, Sophia-Antipolis, France

Graz University of Technology, Austria

Abstract—As DRAM has been scaling to increase in density,
the cells are less isolated from each other. Recent studies have
found that repeated accesses to DRAM rows can cause random
bit flips in an adjacent row, resulting in the so called Rowhammer
bug. This bug has already been exploited to gain root privileges
and to evade a sandbox, showing the severity of faulting single
bits for security. However, these exploits are written in native
code and use special instructions to flush data from the cache.

to any architecture, programming language and runtime environment that allows producing an efficient stream of memory
access instructions. The main challenges to perform this attack
are finding an optimal eviction strategy as replacement for
the flush instruction and retrieving sufficient information on
the physical addresses of data structures in JavaScript to find
address pairs efficiently.

In this paper we present Rowhammer.js, a JavaScript-based
implementation of the Rowhammer attack. Our attack uses an
eviction strategy found by a generic algorithm that improves the
eviction rate compared to existing eviction strategies from 95.2%
to 99.99%. Rowhammer.js is the first remote software-induced
hardware-fault attack. In contrast to other fault attacks it does
not require physical access to the machine, or the execution of
native code or access to special instructions. As JavaScript-based
fault attacks can be performed on millions of users stealthily
and simultaneously, we propose countermeasures that can be
implemented immediately.

We describe an algorithm to find an optimal eviction
strategy for an unknown cache replacement policy. Existing
eviction strategies either focus on the pseudo-LRU cache
replacement policy as implemented in Sandy Bridge [6], [7].
On Haswell and Ivy Bridge CPUs these eviction strategies
show a significantly lower eviction rate. While the LRU
eviction strategy achieves an eviction rate of 95.2% on our
Haswell test machine, our optimal eviction strategy improves
the eviction rate to 99.99%. Furthermore, our eviction strategy
is more efficient in terms of additional memory accesses and
time consumption. Both are crucial to successfully exploit the
Rowhammer bug.



Hardware-fault attacks have been a security threat since the
first attacks in 1997 by Boneh et al. [1] and Biham et al. [2].
Fault attacks typically require physical access to the device
under attack to expose it to physical conditions which are
outside the device specification. This includes high or low temperature, radiation, as well as laser on dismantled microchips.
However, software-induced hardware faults are also possible,
if the device under attack can be brought to the border or out
of the specified operation conditions using software.
Recently, Kim et al. [3] showed that frequently accessing
specific memory locations can cause random bit flips in DRAM
chips. These random bit flips can even be triggered by software
by flushing the memory location from the cache and reloading
it. In early 2015, Seaborn [4] demonstrated how an attacker
can exploit such bit flips to get access to the physical memory
of the machine from inside the Chromium sandbox or from an
unprivileged user program. However, these exploits are written
in native code and use special instructions to flush data from
the cache. A recent tech report by Xuanwu Labs [5] suggests
that this is not possible because the attacker can not trigger
the flush instruction appropriately from scripting languages.
In this paper, we present an implementation of the
Rowhammer attack that is independent of the instruction set
of the CPU. Our attack is the first remote software-induced
hardware-fault attack. It is implemented in JavaScript in Firefox 39, but our attack technique is generic and can be applied

As a proof of concept we implement our attack in
JavaScript. JavaScript is a scripting language implemented in
all modern browsers to create interactive elements on websites.
We do not exploit any weaknesses in JavaScript or the browser.
Rowhammer.js is possible because todays JavaScript implementations are well optimized and achieve almost native code
performance for our use case. JavaScript is strictly sandboxed
and the language provides no possibility to retrieve virtual or
physical addresses. However, the usage of large pages allows
determining parts of the physical address.
We compared our implementations of the Rowhammer
attack on the three different machines shown in Table I.
While two are susceptible to the Rowhammer attack using
the flush instruction, one of them was also vulnerable against
the Rowhammer attack without the flush instruction. The third
machine was only vulnerable to the Rowhammer attack with
an increased refresh rate. The probability of a bit flip is
significantly higher when using the flush instruction on all
three machines. However, comparing our native code (without
the flush instruction) and JavaScript implementation we found
a negligible difference in the probability of a bit flip. This result
suggests that if bit flips can be observed using our native code
implementation the system is vulnerable to remote JavaScriptbased attacks.
We still need to investigate how many systems are vulnerable to Rowhammer.js. Since the attack can be performed on

The mapping for one Intel Sandy Bridge machine in one configuration has been reverse engineered by Seaborn [8]. Multi-channel memory architecture increases the transfer speed of data. A. [12]. that are further composed of banks. Each DIMM contains one or two ranks.js can be exploited for sandbox escaping or privilege escalation. i. • We developed a tool to translate JavaScript array indices to physical addresses in order to trigger bit flips on known physical memory locations from JavaScript. The Rowhammer bug The increase of DRAM density has led to physically smaller cells. Accesses to different banks can be served concurrently. we provide background information on DRAM and the Rowhammer bug. • We built a pure JavaScript implementation which scans the memory efficiently for vulnerable addresses. not in rows that are directly accessed. that are physical links between the DRAM memory and the memory controller. each row is refreshed in a certain interval. on Intel and AMD CPUs. DRAM and CPU manufacturers have known the Rowhammer bug since at least 2012. the cells have a lower noise margin. Kim et al.TABLE I. Summarizing. The Rowhammer bug has only been studied recently in academic research [3]. we describe how CPU caches in modern Intel CPUs work and related work on cache attacks. In particular. • We built a native code implementation of the Rowhammer attack which only uses memory accesses. hammering a DRAM chip is one of the quality assurance tests applied to modules. [10]. • We discuss how a JavaScript-based Rowhammer attack can be used by a remote attacker to gain access to the physical memory of a system. typically 8 on recent DRAM. In Section V. Their proof-of-concept implementation frequently accesses and flushes two different memory locations in a loop. . Platform Lenovo T420 Lenovo x230 Asus H97-Pro CPU i5-2540M i5-3320M i7-4790 E XPERIMENTAL SETUPS . We verified that it finds an optimal eviction strategy on Sandy Bridge. A channel consists of multiple Dual Inline Memory Modules (DIMMs). As a result. we describe the JavaScript implementation and compare it to the native code implementation and the original implementation with the flush instruction. that are the physical modules plugged into the motherboard. date of the filing of several patent applications by Intel [9]. typically 214 to 217 . which also clears the row buffer before a new row can be opened. We suggest countermeasures to be implemented immediately to prevent possible attacks. Each bank has a row buffer where the memory accesses are served from. called the refresh interval. [3] studied the vulnerability of off-the-shelf DRAM modules to bit flips. our key contributions are: • We describe an algorithm to find an optimal eviction strategy for an unknown cache replacement policy. thus capable of storing smaller charges. II. and writes it back immediately. future work has to show whether Rowhammer. This function can vary between different systems and system configurations. Furthermore. Refreshing a row is the same operation as opening the row. They built a program that induces bit flips by software using the clflush instruction. rank. Each bank is a two-dimensional array of capacitor-based cells. DRAM manufacturers optimize the refresh rate to the lowest value that still has a probability of virtually zero for bit flips to occur accidentally.e. BACKGROUND AND R ELATED W ORK In this section. forcing the CPU to serve the next memory access from the DRAM instead of cache. • We propose countermeasures to be implemented immediately to prevent attacks on millions of users. Although they discussed how to exploit these bit flips for privilege escalation attacks. B. we provide conclusions in Section IX. we evaluate the optimal eviction strategy on Haswell by analyzing the eviction rate and performing a Rowhammer attack in native code without the flush instruction. but Intel does not. The bank is thus represented as a collection of rows. [11]. as reading the charge destroys the data. which represents a binary data value. The selection of channel. As refreshing DRAM cells consumes time. but rather in rows nearby the one accessed.. DDR3 DRAM specifications require refreshing all rows in a 64ms time window [3]. In fact. The row buffer reads the charge from the cells. bank and row is done by a subset of physical address bits. DRAM A memory system can have a single channel or multiple channels. as well as modern CPU caches and cache attacks. Furthermore. The clflush instruction flushes data from all cache levels. We discuss countermeasures against our attack in Section VII and future work in Section VIII. Each rank is a collection of chips. Finally. Access to the DRAM is done in three steps: 1) opening a row. The so called Rowhammer bug consists in the corruption of data. they did not provide an exploit. The remaining paper is organized as follows. Ivy Bridge and Haswell CPUs. To prevent data corruption. In Section IV. 3) closing the row. that correspond to the sides of the physical module. AMD documents the addressing function used by its processors. Architecture Sandy Bridge Ivy Bridge Haswell RAM Corsair DDR3-1333 8 GB Samsung DDR3-1600 4 GB (2×) Kingston DDR3-1600 8 GB an arbitrary number of victim machines simultaneously and stealthily it poses an enormous security threat. We verified that the attack is successful on Ivy Bridge and Haswell CPUs. DRAM is volatile memory and discharges over time. A cell is either in a charged or discharged state. We describe the adaptive eviction strategy algorithm in Section III. 2) accessing the data by reading and/or writing any column. it reads and restores the charge of the cells. causing bit flips in a third memory location. we give an introduction to DRAM and the Rowhammer bug. In Section II. and cells can interact electrically with each other although they should be isolated.

it can access the whole physical memory of the system. [22]. Kim et al. i. In case of a dual-core CPU.. thus memory accesses and cache evictions directly influence the other cores. This effect is exploited in cache side-channel attacks [16]. CPU cache addressing A modern CPU cache is a small and fast memory inside the CPU. In case of a quad-core CPU. Cache side-channel attacks exploit timing differences between cache hits and cache misses. called lines. [19] and Seaborn [20] in Table II. without providing any implementation details [17]. Address Bit 3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 2 cores o0 ⊕ ⊕⊕⊕⊕⊕ ⊕ ⊕ ⊕⊕ o0 ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ 4 cores o1 ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ All caches are organized in coherent blocks of 64 bytes. caused by a bit flip in an instruction sequence for indirect jumps. although parts of it apply to other processors as well. the L3 cache is divided into as many slices as CPU cores. The L4 cache is present in some Haswell and Broadwell CPUs. We have combined the results by Hund et al. for each activation of a given row. The second one targets Google Chrome Native Client [13]. However. Common replacement policies are random. a row activation of the neighboring rows with a small probability. Slice 0 Slice 1 Slice 2 Slice 3 Fig.Seaborn implemented two attacks that exploit the Rowhammer bug [4]. The L3 cache is shared among all cores. As the CPU cache is much smaller than the main memory. Cache attacks and cache eviction Cache eviction has ever been a means to perform cache side-channel attacks. thus any unprivileged and possibly sandboxed process can use it. [14] proposed two architectural mitigations to the Rowhammer bug. this instruction is not privileged. 35 6 17 Tag Physical Address Set 30 H 2 0 Offset 11 . Least Recently Used (LRU) or modified variants of LRU. as we show in this paper. used for video memory. However. Seaborn and Birhanu have reported to be able to flip bits on Sandy Bridge CPUs by means of cache eviction. The CPU hides the latency of main memory by keeping copies of frequently used data in the cache. A dummy activation is sent to neighboring rows to refresh the cells when the counter exceeds a threshold. it is unknown whether it is possible to disable the instruction at least for unprivileged processes through a microcode update and so far Intel has not released one. The L3 cache is an inclusive cache. output bit o0 determines to which of the two cache slices the physical address maps. The set is directly addressed. Complex addressing scheme used in the LLC. It thus decides which line to evict. TABLE II. By spraying the physical memory with page tables. however researchers have worked towards its reverse engineering. all data in L1 and L2 cache is also present in the L3 cache. However. D. Current CPUs implement n-way associative caches. The second solution performs. caused by a bit flip in a page table entry. Moreover.. Native Client allows executing sandboxed native code – that included the clflush instruction – through a website. . C. each core can access every slice. C OMPLEX ADDRESSING FUNCTION . these solutions can only be implemented in future DRAM chips. the replacement policies for some architectures have been reverse-engineered. 1. Sandy Bridge has a pseudo-LRU replacement policy and Ivy Bridge a modification of the pseudo-LRU replacement policy [18]. a bit flip in a page table has a high probability to replace the previous mapping with the mapping of a process owned page table. However. Intel has not disclosed the cache replacement policy of their CPUs. Since the Nehalem microarchitecture. If a process can modify its own page table. The slice is given by a hash function that takes as input a part of the physical address. However. Cache attacks were first mentioned by Kocher [21] and Kelsey et al. as well as to hold data evicted from the L3 cache.. output bits o1 and o0 are used to determine to which of the four cache slices the physical address maps. The first solution uses a counter for the number of row activations. It means that a line is loaded in a specific set depending on its address only. not all data can fit in the cache. In this document we only discuss Intel processors. that takes as an input part of the physical address (see Figure 1). and where to place the new line. in any of the n lines. The replacement policy predicts which cache line is least likely to be accessed in the near future. This shows that the Rowhammer attack using clflush was only one attack path. Intel processors have 1 to 4 levels of cache. where L1 is the smallest and fastest cache and L4 the slowest and largest cache. The complex addressing function is undocumented. The first one is a kernel privilege escalation on a Linux system. At the hardware level. However. The table shows how address bits 17 to 31 are xor’d into one or two output bits o0 and o1 . At the software level.e. while the underlying problem is a timing issue and therefore independent of access to specific instructions. the clflush instruction was removed from the set of allowed instructions in Google Chrome Native Client [15]. The mapping from physical addresses to cache slices is performed by a so called complex addressing function. we provide an adaptive eviction strategy that works on more recent CPUs like Haswell and Ivy Bridge as well. The removal of the clflush instruction from the instruction set was already suggested as a countermeasure to cache attacks in native and virtualized environments [16]. cache eviction can be used as an efficient replacement to clflush. and are not portable to currently deployed chips. The attack is an escape of Native Client sandbox. from which an attacker could take control over the system.

as can be seen from the peak at 230 cycles and the access times above. Bridge uses a pseudo-LRU replacement policy. more recent CPUs like Ivy Bridge and Haswell use adaptive cache replacement policies which are only pseudo-LRU in corner cases. The time taken by the prime step is directly proportional to the number of ways that have been replaced by other processes including the victim process. the physical address to evict is evicted with a high probability. As described in Section II-C. Hund et al. Consequently. However. We see that in case of the flush instruction no memory accesses . As shared memory is not always available between attacker and victim process. to serve memory accesses from the DRAM instead of cache. Figure 3 shows the access time histogram. the probability of eviction is significantly lower in case of the LRU eviction strategy than with our adaptive eviction strategy. an attack technique that allows determining which specific cache sets have been accessed by a victim program. Liu et al. after accessing as many congruent locations as the number of ways of the L3 cache (typically 12 or 16). Figure 2 shows the best eviction strategy we found for Haswell CPUs. III. they determine whether a process under attack has reloaded the data in the meantime. Wong [18] observed that dual-pointer chasing can help to cause eviction on Ivy Bridge with a similar probability as on Sandy Bridge. However. In order to do so. Excerpt of optimal access pattern on Haswell. by means of a timing attack. It is also crucial for the Rowhammer attack. thus in terms of the number of memory accesses (cache misses). on Ivy Bridge and on Haswell CPUs the address is more likely to be evicted if it is accessed three times. Both. Therefore. The first address and the last address are not accessed as often. Therefore. We found that this strategy works on Ivy Bridge and Sandy Bridge as well. Powerful cross-VM side-channel attacks [6]. The third access tricks the CPU to keep the data in the cache. Ivy Bridge and following microarchitectures use a slightly different replacement policy called Quad-Age LRU [32]. In 2006 Osvik et al. [7] presented algorithms to find optimal eviction sets on Sandy Bridge microarchitecture. [6] and Oren et al. 1 2 3 4 5 6 7 8 9 Time Fig. some ways of the cache set remain occupied by the same data all the time and a smaller number of cache misses occurs. works by frequently flushing a cache line using the clflush instruction instead of evicting it by means of memory accesses. so they are more likely to be evicted. we want to find a set of addresses which are congruent in cache. then one access to a second physical address and then a third access to the first physical address again. On our test machine it takes more than 200 cycles to fetch data from memory. as a smaller number of accesses would already suffice. our adaptive eviction strategy and for comparison. To quantify the advantage of our adaptive eviction strategy we performed 12 million memory access on a fixed address which is supposedly evicted. Our goal is to optimize cache eviction in terms of the execution time of the eviction function. 2. However. Priming a cache set evicts all victim data stored on congruent addresses. Both propose eviction strategies for pseudo-LRU cache replacement policies. Their attack called Flush+Reload. [29] have demonstrated that the Flush+Reload attack is possible without the clflush instruction with only a small loss in accuracy. [30] and covert channels [31] have been presented in the last year.Attacks by Gullasch et al. By measuring the time it takes to reload the data. The first two accesses per memory location avoid data to be evicted immediately. Our measurements indeed show that accessing a memory location twice is not sufficient to trick the CPU to always keep it in the cache as long as possible. [28] and Yarom and Falkner [16] exploit shared memory and can thereby determine more accurately the memory locations accessed by a victim program. Gruss et al. the algorithm is not applicable to Haswell CPUs. the mapping from physical addresses to cache slices and cache sets is fixed. Sandy Address Later practical attacks on cryptographic algorithms have been explored thoroughly [23]–[26]. as they do not consider accessing addresses more than once to trick the cache replacement policy. Although these algorithms can work on Ivy Bridge and Haswell under certain circumstances. They evict data from the cache by accessing large memory buffers. his approach uses chained lists which have the drawback to be slow. we will show that our adaptive eviction achieves a significantly higher accuracy on these new architectures. recent cache attacks use the Prime+Probe technique again. However. However. this takes significantly more time and memory accesses than are necessary for the eviction of one specific cache line. even if memory sharing between guests is disabled. We compared eviction using the LRU eviction strategy. but it is not optimal for Sandy Bridge. we can exactly compute which physical addresses are congruent in cache to the physical address to evict – the eviction set. [19] described that it is possible to evict data from the cache by filling a large memory buffer the size of the cache. In the following Section. as it is frequently used. However. That is. The pattern uses two accesses to the same physical address. At the same time. the clflush instruction. due to the new replacement policy used since Ivy Bridge. as well as an access pattern which accesses a minimal number of these addresses. they are not optimal in the numbers of accesses (cache misses) and the execution time. as all accesses are cached it does not incur a significant performance penalty either. [27] proposed Prime+Probe. A DAPTIVE C ACHE E VICTION S TRATEGY Evicting data from the cache is crucial to cache attacks like Flush+Reload. Most accesses in our test were fetched from memory. The replacement policy influences the number and the patterns of accesses needed for the eviction strategy. Oren et al. Both use the clflush instruction for this purpose. This allows performing attacks across virtual machine borders. Moreover. [7] successfully implemented a Prime+Probe cache attack from within sandboxed JavaScript to attack user-specific data like network traffic or mouse movements. they determine which addresses are congruent to each other.

[6]. As we find the access pattern dynamically. Using this algorithm. like the JavaScript-based cache attack by Oren et al. . we can compute an optimal eviction strategy and subsequently evict cache lines with a high probability without using the clflush instruction. This technique is dubbed “double-sided hammering”. In case of the LRU eviction strategy 577319 accesses (4. the function returns true and false otherwise.8%) had a timing significantly below 230 cycles and therefore must have been cached. Furthermore. However. The current implementation of our algorithm is significantly slower than the ones by Oren et al. Each memory address is accessed multiple times. We verified the probability of the eviction by measuring the access times on the two addresses to evict. We now seek to minimize this eviction set. I MPLEMENTATION OF ROWHAMMER CLFLUSH IN NATIVE C ODE WITHOUT We found on all our test machines a significantly higher probability for bit flips in a row N when hammering its neighbor rows N − 1 and N + 1. but is now represented in the array instead of the loop code. The memory access pattern stays similar to the one described before. In the final step we randomly remove all accesses which do not influence eviction. the LRU eviction strategy yields 648 times as many cache hits than our adaptive eviction strategy. it is necessary to achieve optimal eviction and as it is executed before the hammering loop it does not influence the attack itself. we are able to exploit the Rowhammer bug using this eviction strategy.0001%) with a timing significantly below 230 cycles. Therefore. We replace all accesses to addresses which have no influence on eviction with accesses to other addresses from the eviction set. by performing a timing attack. are below 230 cycles. based on the specific system. In the first step the adaptive eviction set finding algorithm continuously adds addresses to the eviction set. the number of memory accesses does not decrease. Thus. 3. That is. no accesses are cached. We know that the eviction set is large enough as soon as we can clearly measure the eviction of the target physical address. as we discuss in the next Section. With our adaptive eviction strategy. To achieve a high accuracy. This allows improving existing cache attacks which are based on Prime+Probe. The second variant is shown in Listing 2. We have used a similar unrolled version of this loop on Ivy Bridge. but the number of different addresses decreases to the minimum. Input: Target address p Access p while cached(p) do Choose random 64-byte-aligned address r from eviction buffer Insert r into eviction set twice e at two random positions end Set c = 0 while c < |e| and not cached(p) do Choose random index r in e Store all indices ri where e[r] = e[ri ] Replace all e[ri ] with e[ri − 1] if cached(p) then Undo changes for all indices ri Set c = c + 1 else Set c = 0 end end Set c = 0 while c < |e| and not cached(p) do Remove random element from e if cached(p) then Undo changes Set c = c + 1 else Set c = 0 end end Therefore. IV. Algorithm 1: Adaptive Eviction Strategy Algorithm. eviction and access are performed between 16 and 1 million times. Here the eviction set is computed by exploiting timing differences instead of physical addresses. If a single cache hit was measured. all accesses are fetched from memory. We extended the double_sided_rowhammer program by Seaborn [20] by using the adaptive eviction strategy from the previous Section. [7] and Liu et al. The result of the algorithm is an optimal access pattern for the system under attack. The cached(p) function tries to evict using the current eviction set and decides whether an access was cached or not based on the access time. The eviction sets are precomputed in the f_evict and s_evict variables. The two clflush instructions were first replaced by the eviction code shown in Listing 1 on Haswell. we designed the algorithm shown in Algorithm 1 that finds an adaptive eviction set. to reduce the probability of immediate eviction. Thus. in our proof-of-concept attack we use it only to find optimal eviction strategies in a preprocessing step. Comparison of different eviction strategies on Haswell.Number of Accesses LRU Evict Adaptive Evict Flush 107 104 101 0 100 200 300 400 500 Cycles Fig. [6] on newer CPUs significantly. regardless of the replacement policy. the strategy is adaptive to all cache eviction schemes. This decreases the number of cache misses and the execution time. [7] or the cross-VM cache attack by Liu et al. we measured 891 accesses (less than 0.

]. On our Haswell test machine we were not able to reproducibly flip bits with the default settings. VI. For each of the 19 possible row offsets all page offset combinations are hammered. We have observed that adding dummy instructions – that only consume time – while hammering sometimes increases the number of bit flips significantly. As a work around we used large typed arrays. memory access have to be implemented in a way that they cannot be optimized out by the just-in-time-compiler. In order to do that we built a tool which monitors the virtual address space of Firefox. we know that each 2MB region of our array consists of either 16 rows of size 128KB (single channel) or 8 rows of size 256KB (dual channel). i += 1 ) { ∗f evict [ i ]. i += 1 ) [i [i [i [i [i [i [i [i ]. We then resolve the physical addresses we want to hammer to offsets within the JavaScript array. Thus. V. With 32 pages per row and channel there are 256 combinations to hammer pages per row and channel. as the BIOS configuration allows setting a custom refresh rate. thereby reducing the probability of bit flips. which is counterintuitive with the fact that the bit flips should occur more often with a higher hammering rate. Instead we use our adaptive algorithm from Section III. During the tests the system was under slight usage (browsing. i < COUNT( f e v i c t ) . However. etc. More attention should be given to this phenomenon. ATTACK E VALUATION We have evaluated how different refresh rates influence the number of bit flips (expected value based on our measurements) in Figure 4 for a fixed address pair and a fixed time interval in different setups. resulting in the first remote JavaScript-based hardware-fault attack.1 2 3 4 5 6 7 8 9 10 11 for ( s i z e { ∗f evict ∗s evict ∗f evict ∗s evict ∗f evict ∗s evict ∗f evict ∗s evict } Listing 1. Hand-crafted eviction loop on Haswell f o r ( s i z e t i = 1 . ]. we found that the access pattern from native code is not optimized out. as described in the next Section. i < COUNT( f e v i c t ) . . ROWHAMMER IN JAVA S CRIPT Several challenges have to be addressed to trigger the Rowhammmer bug from JavaScript. In a second step we build an inverted page table for the Firefox process. we were able to analyze its influence. which is necessary for the attack. [7]. we were able to reproducibly flip bits on our Ivy Bridge test machine. The bit flips per round are shown in Figure 5. +1]. } Listing 2. The machine was operated in default configuration for the DRAM and was mostly idle (internet surfing) during our tests. Although it is slower than the ones by Liu et al. We performed most tests on the Haswell machine as we were able to change the refresh interval. These are the only two building blocks.). However. The eviction set is computed using the adaptive eviction strategy finding algorithm from Section III. not even with the clflush instruction. However. We reproducibly flipped bits using the optimal Haswell eviction strategy at lower refresh rates. and to whether it can be used for countermeasures against the Rowhammer bug. Each time a 2MB page is allocated we store the virtual address and the time difference to the last allocation. We used this setup as a development platform for the proof of concept Rowhammer implementation in JavaScript. JavaScript has no concept of virtual addresses or pointers. However. the DRAM chips and the CPU. Generic eviction loop on Haswell Using the adaptive eviction strategy. +1]. a high hammering rate would trigger a higher DRAM refresh rate. Thus. ∗s evict [ i ]. we only observed bit flips when the CPU was running at the maximum frequency of 3. We can see that the expected number of bit flips per round is significantly lower in case of the eviction-based tests than in the tests with clflush. We observed that large typed JavaScript arrays are allocated on anonymous 2MB pages. Future work includes investigating whether the update successfully prevents bit flips on this test machine. This way we can detect the beginning of the allocation in JavaScript. +1]. As it is not possible to set the DRAM refresh rate on this machine in the BIOS settings. Thus. This effect occurred in both JavaScript and native code. only by knowing the offset in the array we know the lowest 21 bits of the virtual and physical address. The probability for bit flips in JavaScript and in native code is almost the same. ]. The final JavaScript-based attack exploits the fact that large typed arrays are allocated on 2MB pages. a successful remote attack will only be possible on the Ivy Bridge laptop as it has a significantly higher probability of bit flips without clflush in default settings. As a first proof of concept we tried to reproduce bit flips we found in JavaScript in Firefox 39. typing in an editor. if a machine is vulnerable using our native code implementation it is vulnerable using our JavaScript implementation as well. We see that the clflush instruction yields the highest number of bit flips. it finds a significantly better eviction strategy. We still have to do more experiments on this machine to exactly find the preconditions in terms of temperate ranges of the environment. Lenovo has released a BIOS update for this machine doubling the refresh rate of the DDR3 module. These instructions increase the execution time of each hammering loop. we could not examine the influence of the refresh rate on the number of bit flips. this leads to the second problem: we cannot compute eviction sets based on physical addresses in JavaScript. These offsets are then pasted into a field in the webpage to start hammering on the JavaScript array. First. in cases where the DRAM has a dynamic refresh rate. [6] and Oren et al. However. We suspect that. The number of rounds that have fit into the fixed 15 minutes interval have varied a bit for the test runs at different refresh rates. Third. 1 2 3 4 5 t i = 1 .3GHz. Native code eviction and JavaScript eviction are very close together and the difference between those two is negligible. +1].

However. as long as the stream of memory accesses is executed fast enough. While we cannot memory map files in JavaScript. we presented Rowhammer. However. Rowhammer. We chose JavaScript because it can easily be executed by a remote attacker. If now a bit flips in one of the page tables the exploit notices that the file is not mapped anymore and as it has filled the memory with its own page tables. according to Kim et al. to prevent bit flips caused by row hammering. 4. Although implemented in JavaScript. If the memory is accessed in the same pattern and the frequency is high enough it will cause bit flips as well. VII. Unless the system was successfully tested to be most likely resistant to the Rowhammer bug. other languages like ActionScript or server-side scripting languages could also be interesting targets for an attacker if they are translated to a native instruction stream by a compiler or JIT-compiler. Even when the system is most likely resistant. JavaScript should be slowed down to eliminate the possibility of an exploit. e. We assume that comparatively complicated BIOS updates will only be deployed by a diminutive group of users. Some hardware manufacturers have already started to distribute BIOS updates. By acquiring a large number of zero pages we could fill the memory with our own page tables like in the native code exploit. it would then consume up to 35% of time..g. Having access to our own page tables from JavaScript would enable us to access and modify all physical memory. C OUNTERMEASURES Kim et al.Bit Flips Flush Evict (Native) Evict (JavaScript) 104 VIII. we observed that if the operating system or hypervisor deduplicates zero pages we can achieve a similar situation.js is the first remote hardwarefault attack. While the DRAM is currently busy refreshing up to 4. . the problem is bigger than that. There is also the issue of whether end users will actually patch their machines. if the JavaScript justin-time compilation is as efficient. To prevent attacks on millions of users. JavaScript eviction. it is necessary to allocate 4KB pages. Until now this might have affected the stability of the system. 5. IX. [3]. While we implemented a successful attack in JavaScript in Firefox 39. Seaborn [20] built a root exploit which first tries to find a memory location causing a reproducible bit flip and then tries to fill the memory with its own page tables.js. an implementation of the Rowhammer attack using optimal cache eviction through memory accesses. One way to get root privileges is by spraying the physical memory with page tables. we expect the attack to work in other browsers as well. One countermeasure they propose is increasing the refresh rate. AMD x86 or ARM CPUs. programming language and runtime environment. which is enabled by default [33]. it probably has one of our its page tables mapped. If this is the case page tables can be in a row between the two rows being hammered. Modern smartphones have fast DRAM modules integrated and should be examined for potential security risks. native code eviction. we know that a root exploit must be possible and we will investigate this next. 102 100 0 1 2 3 4 5 6 Refresh Interval 7 ·104 Fig. it is necessary to evaluate how it performs on non-Intel platforms. Flush Evict (Native) Evict (JavaScript) 102 Bit Flips the user should explicitly agree to activate JavaScript when opening a website. If this is the case the program has full access to physical memory. although Windows comes with an auto-update feature. More general.5% of the time. native code eviction. We found several guides suggesting to decrease refresh rates to gain higher system performance. Number of a bit flips per round (expected value based on our measurements) on a fixed address pair for different refresh rates on Haswell in the three different setups: clflush. we do not provide a full root exploit. as in the native code exploit by Seaborn [20]. JavaScript eviction. users cannot do this anymore without risking a remote attacker performing fault attacks against their systems. First. solving the problem for most but not all machines. [3] proposed several countermeasures which should be implemented for new DRAM modules. To exploit bit flips in page tables using double sided hammering. the attack technique is independent of the specific CPU microarchitecture. Number of bit flips within 15 minutes (expected value based on our measurements) on a fixed address pair for different refresh rates on Haswell in the three different setups: clflush. Although our eviction-strategy-finding algorithm (presented in Section III) works on different Intel CPUs. As it is possible in JavaScript to get 4KB pages and 2MB pages. 101 100 0 1 2 3 4 5 Refresh Interval 6 7 ·104 Fig. A report shows that only 30% of Windows systems are up-to-date. Most of these updates only double the refresh rate. the refresh rate would need to be increased to 8 times its current value. we propose adding Rowhammer tests to browsers. C ONCLUSIONS In this paper. the presented approach can be applied to any programming language and any runtime environment. Now. F UTURE W ORK Although we demonstrated how the Rowhammer bug can be triggered from JavaScript.

“S$A: A Shared Cache http://lackingrhoticity. J. pp. and O. Seaborn. Schneier. US Patent App. We expect that a remote [18] H. map to rows and banks in [3] Y. client?revision=13809&view=revision. Hund. “Last-Level Cache [28] D. 5 2014. and H. Sodhi. Chao. [22] J. 2014. G. Shigeri. DeMillo. Checking Cryptographic Protocols for Faults. Shamir. O. Yarom and K.” Journal of Computer Security. vol.” in IEEE Symposium on Security web browsers immediately to avoid remote attacks on millions and Privacy – S&P.-F. Wells.” in Advances in Cryptology – CRYPTO. “Exploiting the DRAM rowham[25] D. “Native Client Revision 13809. L3 Cache Side-Channel Attack. of users. 513–525. http://daemonology. “Rowhammer without Hall. LNCS. [4] M.iacr. Symposium on Computer Architecture – ISCA. 104–113. Cores Cache Covert Channel. vol. 2015.” https://developer.-h. Holz.” in Proceedings of the 2014 IEEE International Integrated on July 16. P. Sethumadhavan. we still found that one machine is vulnerable to our attack with default settings. Suzaki. Our attack runs in sandboxed JavaScript which is present [17] Zelalem Birhanu Aweke.415. [Online]. retrieved on July 16. Springer. [15] Chrome Developers. J. Kim. E.523.” in International graphic Hardware and Embedded Systems – CHES. 1–20. retrieved on mer bug exploits to our attack. Lin. 1997.” in Advances in Cryptolser. 2015.blogspot. 2015. J. Mangard. I. [31] C. [13] Chrome Developers.99% on our Haswell test system compared to existing eviction strategies. 1294. S. Park. [1] D. 2015. “How physical addresses 2015. Huang. [20] M.” in USENIX Security Symposium. Lipton. 2015.Practical Cache Attacks [29] [32] S.github. 490–505.07373 Security Symposium (USENIX Security 15). T. pp. vol. Side-Channel. [2] E. USENIX Association. Francillon.” in Proceedings of the 49th Annual Design Automation http://hotchips.” attacker can gain root privileges by adapting existing Rowhamhttp://blog. Tsunoo. Wagner. A.” in Proceedings of the 12th International [10] K. Gruss. Yarom. Yang. Available: https://google. “Theoretical Use of Cache Memory as a Cryptanalytic International Cryptology Conference.” [27] D. Maurice. 2012. Wen. George. Available: http://eprint.” CoRR. Page. R. “On the Importance of RSA. retrieved on June 26. and R. Assessment (DIMVA’15). Osvik. M. R. pp. 8. Springer. Efficient countermeasures are July 16. Kim. “Timing Attacks on Implementations of Diffie-Hellman. 1233. Baeg. Bains and J. case study. Biham and A. J. Springer. Reliability Workshop Final Report (IIRW’14). “Antivirus and Operating System Report: October 2014. “Intel Ivy Bridge Cache Replacement Policy. Schoenborn. and R. Seaborn. “Flipping bits in memory without accessing them: analysis of DES Implemented on Computers with Cache.” Jan. its Application to AES. DSS. T.” 2004. June 2015. Low Noise. LNCS.” in IEEE Symposium on Security Access-Based Cache Attacks on AES to Practice. we [19] R. pp. “Cache Games – Bringing Side-Channel Attacks are Practical. Although the probability of a bit flip is significantly lower than with the flush instruction on our test machines. 2014. 2006. D. and A. and [24] Y. C. September 2014. Bains. 2015. Saito. “Power [11] R. Miyauchi. 13/690. retrieved on June 26.” and enabled by default in every modern browser. and S. J. V. retrieved on June 26. Nair. 141–158.html. Neumann. K. ser. C. This high accuracy is a crucial to exploit the Rowhammer bug without the flush instruction. hammer threshold value.” in 24th USENIX http://arxiv. “Architectural Support for Mitigating Row Hammering in DRAM uRL: March 2015. “Cache Attacks and Counterhttps://xuanwulab. retrieved Technology. [12] K. 361–372. 1109. Fallin. C. Additionally. “L3 cache mapping on Sandy Bridge CPUs. Shamir. 2000. H.-Y. Heen. Q. and Z. 62–76. and R. Lee.” in Advances in Cryptology . and A. Falkner. pp.CRYPTO ’97.-T. Kemerlis. 17th Annual [23] D. Ge. D. [Online]. [Online]. IEEE. Sunar. Bernstein. ser. “Cache Template Attacks: in Javascript. IEEE Computer Society. “Side Channel Crypt37–51. “Row hammer monitoring based on stored row – S&P. “Research report on using JIT to trigger RowHammer . 1996. R EFERENCES [21]” in IEEE Symposium on Security and Privacy [9] K. [5] XuanwuLab. C.” 2005. Available: Automating Attacks on Inclusive Last-Level Caches.yp. USENIX Association.07373. 2011.blogspot. Mozak.” IACR Cryptology ePrint Archive 2002/169. and T. Boneh. it https://groups. US Patent!topic/rowhammer-discuss/ojgTgLr4q M. “Native The optimal eviction strategy we found improves the eviction rate from 95. 1. “CryptK. [7] Y. S. H.” in IEEE Symposium and Privacy – S&P. 13/539. LNCS. P. Qureshi. uRL: mer bug to gain kernel privileges. 2779. Mutlu.EUROCRYPT ’97. D. C. 1012–1017. . can be launched from any website. Kocher. Y. Therefore. no. “Row Conference on Detection of Intrusions and Malware. known but seem unlikely to be practical.” Jun. Halbert. ogy . 2014. “Differential fault analysis of secret key 2/3.-C. “Cache-Timing Attacks on AES. 1997. 2015. Tromer. [16] Y. Lee. Wong. C. Wong. and Other Systems. [6] F. Oren. pp. Liu. http://googleprojectzero. Available: https://google. R. and Vulnerability hammer refresh command.chromium. 2003. 14. retrieved on July 20.” http://lackingrhoticity. M.” Hot Chips 2012. on Security and Privacy – S&P. and C.2% to 99.” http://src. 2015. retrieved on July 16. Jahagirdar. and R. Attack that Works Across Cores and Defies VM Sandboxing – and May 2015. 191–205. no. Wilkerson. LNCS. A. T. 2015. LNCS. Keromytis. pp. Heiser. Percival.” in Topics in Cryptology – CT-RSA. “Active-Precharge Ham[33] OPSWAT. Greenfield. retrieved on June 26. Krenn. retrieved on July 16.h April 2015. Gullasch. S. Daly. ser.The optimal eviction strategy we used can be found for an unknown CPU by a generic algorithm we propose. May 2015. and M. abs/1502.” [30] G. 2 2014. “FLUSH+RELOAD: A High Resolution. 2015. pp. 9–12. July 2015.” mering on a Row Induced Failure in DDR3 SDRAMs under 3x nm https://opswat. “Cache Missing for Fun and Profit. 2013.stuffedcow. B. Irazoqui. vol. and E. archives/hc24/HC24-1-Microprocessor/HC Conference (DAC’12). “Practical Timing Side Channel propose practical countermeasures which can be deployed in Attacks against Kernel Space ASLR. 82–85.html. 719–732. and” in CryptoAn experimental study of DRAM disturbance errors. pp. Eisenbarth. Lee. [14] D. pp. analysis of Product Ciphers. [8] M. “C5: Cross[Online]. T. ser. Kim. Spreitzer. 2015. Springer.html#cachetiming. vol.” http://cr. 2015. IEEE Computer Society. 3860. vol. 2015. “The Spy in the Sandbox . and S. B. pp. Halbert. pp. measures: The Case of AES. pp. [26] C. vol. A. Seaborn. Lai.” IEEE Computer Architecture Letters. 2014. “Alternate Management of the Third Generation Intel Core Micro hammering test for application-specific DRAMs and an industrial Architecture formerly codenamed Ivy Bridge.