27.07.2015: Daniel Gruss, Clementine Maurice and Stefan Mangard released a paper today detailing how row hammer can be done in java script on Sandy Bridge, Ivy Bridge and Haswell. The method is indeed a pattern read in memory to evict the aggressor address from the cache. They utilize that a cache set only has 12 or 16 entries(ways) and thus using (repeatedly) 13 or 17 addresses that map to a single cache set will cause L3 cache misses on the 13th/17th access, instead of my experiments of keeping the entire cache full (which works like a charm, but it seem too slow for rowhammer). What they ended up with is certainly more advanced that what I've played with, but it's the same ball game. Thus the speculation in the old post below post unfortunately holds true.
It's time to test your ram! Disabling java script will go a long way towards protecting you. White list sites that you consider safe and HTTPS is important to avoid MiM injecting of java scripts. However these measures are insufficient on their own - other advanced scripting languages could probably be abused too (flash, silverlight,....).
A bit more speculation: Apple made an update to their EFI bios to mitigate it. I speculate that they increased the refresh rate, so that there is only 32ms between refreshes instead of the usual 64ms - the reason for this is that a 32ms refresh rate is recommmend for running at high-temperature and thus likely to be readily available. This is insufficient to entirely rule out row hammer as you'd need to drop interval as low as 8ms to be safe. It's important to realize that less time between refresh means speed penalties because you cannot read during the refresh. For 8ms intervals pentalty will be pretty steep, though probably acceptable for 32ms. Also more refresh causes more power consumption. I have seen wildly differing estimate of this, but I speculate that on a running laptop it's not a real issue and if implemented right (say 64ms interval refresh while computer is sleeping) no issue at all .
For the technically inclined Mark Seaborn's blog is an awesome resource:
to be a malware hobbyist. I can write purely speculative blogs. It's like being
a comedian doing news - it's just comedy... And this blog is pretty speculative - sorry.
In my last
post on the subject "Row hammer fix POC and generic root kit detection
using performance counters" I wrote that I doubt that we'd ever see a script version of this
bug. My reasons for this was that scripts are unlikely to use clflush or any
non-temporal (MOVNT)instructions in any predictable manner and would probably
be on the slow end to flush the cache through accessing the it in a pattern
that the CPU wouldn't predict while hammering quickly enough. The first thing
that made me change my mind was when I stumbled upon this article: http://iss.oy.ne.ro/SpyInTheSandbox.pdf
which manipulates the cache and then uses it as a side channel to obtain
information from outside a sandbox through java script. This chipped away on my
confidence. Then came this article https://xuanwulab.github.io/2015/06/09/Research-report-on-using-JIT-to-trigger-RowHammer/
which concludes that JIT compilers would not generate the instructions we
needed for row hammering. This scared me because I'd forgotten all about JIT
compiling. Because while we might be fast enough without JIT, having JIT would definitely
make it fast enough. And finally came a tweet from Lava (@lavados)
So the plot
thickens. I don't know how BloodyTangerine and Lavados are flipping the bits
but if I were a betting man I'd place my money on the an approach like Spy In
the Sandbox. There is a bit of evidence in that direction. The cache is build
differently on different chipsets and this could be a reason to mention it. Conclusion:
I was wrong. My new opinion is that we'll see a java script row hammer exploit.
disclosure: I had 280 char chat with Lava after I wrote this. This conversation
is not part of this blog, because everything was said in private. I dare say
that if this stuff interests you it would probably be worth while following
around a bit with the row hammer after my last blog. The reason that row hammer
doesn't occur naturally all the time in memory is because the cache catches
reads to any address being hammered. This is also why the performance counter
on last level cache works well for detecting and preventing row hammering. To
get around this Dullien and Seaborn (the original row hammer stuff) used the
clflush instruction. I tried to hammer using the MOVNTQ instruction and was not succesful. Then after reading the "Spy in
the sandbox" I started writing up a cache flush routine using multiple
threads inspired by "Spy in the sandbox". The idea behind using
multiple threads is that the biggest cache on modern CPU's is the level 3 cache
and that is shared on all cores (and hyper threads) making it much easier to keeping
the cache full with content unrelated to the row I'm hammering easier. The 1st
and second level caches I don't consider too much of a problem since they quite
small and could probably be kept full with unrelated stuff on a single thread.
Unfortunately I never finished up this code so I'm not sure if it'd actually
work for row hammer. The real issue isn't keeping my hammering row out of the cache,
but doing it while hammering enough to cause bit flips.
Why row hammer in scripts would
be really bad news
and BloodyTangerine is indeed using the method I were playing with - or even a
derivative of it then it's really bad. Mark Seaborn's fix with black listing clflush
in the validator of NaCL sandbox would not extend because now normal mov instructions
would suffice. Even adc, cmp, sub,inc,... would suffice and these are common
and useful instructions. Even worse since browsers all too easy use Java script
row hammer could easily be extend from a local privileged elevation to a full remote
breach of the host attacked. Worse yet such an attack could be inserted
automatically through man-in-the-middle on non https connections. Like the China's
"Great Cannon" in a worst case scenario. You might argue that ECC ram
would mitigate this, but that's only a half truth. ECC will most of the time
reduce it to a DoS attack, but row hammer would from time to time flip more
than 1 bit and dance right through the ECC on the ram. It wouldn't be the
perfect storm because there is a tiny bit of good news, though not much: row
hammer is difficult to weaponize and we know how to defeat it - even if the
method is far more complex than traditional fixes.
xuanwulab (2015): https://xuanwulab.github.io/2015/06/09/Research-report-on-using-JIT-to-trigger-RowHammer/
Oren et al(2015): http://iss.oy.ne.ro/SpyInTheSandbox.pdf
Row hammer fix POC and generic root kit detection using performance counters