Uh Oh - Rowhammer attacks via Javascript

Madpacket

Platinum Member
Nov 15, 2005
2,068
326
126
http://arxiv.org/pdf/1507.06955v1.pdf

""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.”

Looks like this affects Sandy, Ivy and Haswell which likely make up the majority X86 CPU's released in the last five years :)

A little technical but worth the read. This could get ugly fast if weaponized. Still considering putting all your secure services in the Cloud?
 

kimmel

Senior member
Mar 28, 2013
248
0
41
1) It's a DRAM scaling issue not really a CPU bug. There are workarounds to the bug if are so inclined.
2) As was indicated in the previous articles is that ECC memory (eg: the cloud,which you apparently have issue with) this attack is much less likely to work.
 
Aug 11, 2008
10,451
642
126
http://arxiv.org/pdf/1507.06955v1.pdf

""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.”

Looks like this affects Sandy, Ivy and Haswell which likely make up the majority X86 CPU's released in the last five years :)

A little technical but worth the read. This could get ugly fast if weaponized. Still considering putting all your secure services in the Cloud?

Not related to this, but I would never put anything i wanted to be secure in the cloud anyway.
 

ninaholic37

Golden Member
Apr 13, 2012
1,883
31
91
My first thought was "I wonder if that PDF file has a virus?". Get people to read a PDF about viruses that has a virus in it! Hahah click-bait genius.
 

Madpacket

Platinum Member
Nov 15, 2005
2,068
326
126
Seems its realatively easy to counter for Ivy Bridge and forward:

No, not really. From the blog you cite:

"Mitigations and Fix:

This vulnerability exists within hardware and cannot be mitigated by just upgrading software."

It's a DRAM scaling issue not really a CPU bug. There are workarounds to the bug if are so inclined.

Actually it's both, and as already stated this is a hardware issue that can't be fixed easily via software. As the original paper stated, only 30% of corporations patch computers for security vulnerabilities. How many do you think will go around patching computer BIOS's? (only way to currently mitigate via hardware). I personally use noscript but it's not foolproof either and this would only protect against javascript implementations.

DDR4 is unaffected.

Sorry I'm missing where this is stated, can you link to this please?

Not related to this, but I would never put anything i wanted to be secure in the cloud anyway.

Precisely my concern. My guess many here don't work for a large organizations or are exposed to how large amounts of sensitive data are handled. This is a pretty common thing these days. Especially for finance, HR, and even legal departments to outsource portions of their goods to the cloud.

In this case, cloud would be much more secure than some random PC.

I wouldn't assume that, probably true for the average desktop user but when discussing sensitive PII for organizations that data is normally handled internally usually IT departments (security and networking if big enough) via a series of segmentation techniques with a bunch of industry standard security controls implemented. Highly secure companies are starting to outsource things like security operation centres for monitoring, logging, WAF, which is super useful but also expensive. Audits are performed regularly to check against implement security controls. Having full control (or almost full anyway) over your sensitive data is vital in today's world.

Virtualization has helped with the cost and the storing and moving of data but when issues like Rowhammer are discovered it removes confidence in these technologies. *ALL* cloud companies use some form of virtualization (XEN, KVM, VMWare, Hyper-V etc.) for scalability, reliability and cost reasons so this is why I picked on the cloud. Security is the third pillar that these cloud companies trumpeted as for the reasons to move to them.

Also there's a misconception with cloud security. When you move things into the cloud you rely on the vendor to secure most or all of the infrastructure for you but the data itself is fair game (this is up to developers, security testers, etc to protect as it's very easy to screw this up).

Reducing factors are ECC and the memory capacity. More memory, less chance.

More DRAM or ECC as a protection, sure this can help but do you think the attackers won't attempt to work on faster implementations? The researchers used Javascript on purpose to prove a point.

The important takeaway here is this can be done with Javascript today against a huge number of processors (javascript is among the most common ways to perform remote exploits via drive by attacks, phishing etc).

The following conclusion from the article needs to be taken into consideration as well. This will get worse over time. How well do think ARM technologies will fair, how many smartphones exist today?

"In this paper, we presented Rowhammer.js, an implementation
of the Rowhammer attack using optimal cache
eviction through memory accesses. Although implemented in
JavaScript, the attack technique is independent of the specific
CPU microarchitecture, programming language and runtime
environment, as long as the stream of memory accesses is executed
fast enough. Rowhammer.js is the first remote hardwarefault
attack."
 

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
Nobody said software. But rather change BIOS settings for DRAM.

There are 2 options.
Ivy Bridge and forward pTTR.
Sandy Bridge+AMD reduce refresh from 64ms to 32ms.

And DDR4 got TTR per default.
 

kimmel

Senior member
Mar 28, 2013
248
0
41
Actually it's both, and as already stated this is a hardware issue that can't be fixed easily via software.

Actually it's a side effect of DRAM companies being completely worthless when it comes to reliability. Rowhammer exists because shrinking DRAM makes the charge on the cells small enough that you can perturb the neighboring rows with accesses to a line. DDR3 only shows this on specific process nodes. It has nothing to do with the CPU.

Now, Intel and others have additional workarounds in place for recent memory controllers to fix the bugs in the broken DRAM. DDR4 spec also contains new instructions that processors can use to fix the issues in the DRAM as well without the workarounds needed for DDR3. Of course the memory companies only added those instructions after considerable complaints.
 

Madpacket

Platinum Member
Nov 15, 2005
2,068
326
126
Nobody said software. But rather change BIOS settings for DRAM.

There are 2 options.
Ivy Bridge and forward pTTR.
Sandy Bridge+AMD reduce refresh from 64ms to 32ms.

And DDR4 got TTR per default.

You're referencing outdated Seaborn clflush mitigations from that Cisco blog. This new attack uses an adaptive eviction techniques that doesn't rely on the low level, locally accessed clflush function. This new cache eviction technique works on all modern Intel processors.

Also the size of memory appears to not really matter here if I'm reading the paper correctly as the technique does not look for physical rows, it relies more on access times and timing differences.

"We verified the probability of the eviction by measuring
the access times on the two addresses to evict. The second
variant is shown in Listing 2. Here the eviction set is computed
by exploiting timing differences instead of physical addresses.
The memory access pattern stays similar to the one described
before, but is now represented in the array instead of the loop
code."

Even if it did help, changing BIOS settings after deployment, especially among hundreds or thousands of servers isn't a trivial thing to do.

Please read the paper, or at the very least read "VII. COUNTERMEASURES".

The only practical way to defend is against is to issue a new type of DRAM with the fixes in place (like that will happen anytime soon), slowing down javascript (ironic isn't it?, and what browser company would go first? who would put themselves at a competitive disadvantage), or using something like noscript.

Although there are plenty of other vulnerabilities that are easier to exploit this is a security nightmare with no simple software or hardware solution to fix it.
 

ShintaiDK

Lifer
Apr 22, 2012
20,378
145
106
DDR4 Target Row Refresh completely kills Rowhammer methods. And this method is supported on Ivy Bridge and forward with DDR3 as pTTR.

And the paper list the other method with decreased row refresh for Sandy Bridge+AMD that increase power consumption.
 

Madpacket

Platinum Member
Nov 15, 2005
2,068
326
126
DDR4 Target Row Refresh completely kills Rowhammer methods. And this method is supported on Ivy Bridge and forward with DDR3 as pTTR.

And the paper list the other method with decreased row refresh for Sandy Bridge+AMD that increase power consumption.

No TRR doesn't completely kill Rowhammer, it's a mitigation technique that may protect against the findings by Seaborn . Also it's unrealistic to expect people to make changes with pTTR on compatible DDR3 DIMMS as it requires changes to the BIOS (either through BIOS update or manual changes within it). And folks without pTTR compatible DIMMS will suffer performance deficiencies. Also this info comes the Wiki and the article which doesn't cite the Rowhammer.js exploit [yet] which again uses a different technique than clflush.

DDR4 has hardware support to protect against traditional Rowhammer techniques and it *should* be enabled by default but that will likely be vendor dependent.

No silver bullet here. Still an issue.
 

Madpacket

Platinum Member
Nov 15, 2005
2,068
326
126
Actually it's a side effect of DRAM companies being completely worthless when it comes to reliability. Rowhammer exists because shrinking DRAM makes the charge on the cells small enough that you can perturb the neighboring rows with accesses to a line. DDR3 only shows this on specific process nodes. It has nothing to do with the CPU.

Agreed except for the last part. The Rowhammer.js exploit is [currently] CPU specific due to the way it works although the paper explains this may not be the case, more investigation is necessary.
 
May 11, 2008
22,532
1,468
126
http://arxiv.org/pdf/1507.06955v1.pdf

""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.”

Looks like this affects Sandy, Ivy and Haswell which likely make up the majority X86 CPU's released in the last five years :)

A little technical but worth the read. This could get ugly fast if weaponized. Still considering putting all your secure services in the Cloud?

I wonder, if dram is overclocked, that it would be more vulnerable for the rowhammer attack. Is this the case ?
Is increasing the access latency of the dram or lowering the clock frequency a way to reduce (not remove ) the row hammer effects ?