# rowhammer attack test positive what to do?

## e3k

http://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html

i see the attack as a statistical brute forcing of memory. the test did run positive one my 4x4GB Corsair DD3. On the page it seems DDR4 is less vulnerabre. Also i have red that ECC should help.

What are your thoughts?

----------

## Voltago

 *e3k wrote:*   

> What are your thoughts?

 

Basically that you're probably going to be fine if you don't allow people to gain access to your machine, i. e. don't set up user accounts for random people wearing shades and black hats, even if they do ask nicely, and don't run publicly accessible servers on your laptop. Otherwise it's wait-and-see if there's maybe a firmware update for newer brand laptops that mitigates/solves the problem (good luck with a three year old piece of consumer crap though).Last edited by Voltago on Sun Mar 15, 2015 4:18 pm; edited 1 time in total

----------

## NeddySeagoon

e3k,

Its a hardware 'feature', there isn't going to be a fix.

Decreasing the refresh period from 64ms to 32ms may mitigate the problem but without making it go away entirely.

If you know how to program the memory controller, the kernel can do that.

Don't let strangers in and don't run Java from dubious websites.

Of course, there are lots of reasons not to run Java, this is just one more.

----------

## The Doctor

 *e3k wrote:*   

> http://googleprojectzero.blogspot.de/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
> 
> i see the attack as a statistical brute forcing of memory. the test did run positive one my 4x4GB Corsair DD3. On the page it seems DDR4 is less vulnerabre. Also i have red that ECC should help.
> 
> What are your thoughts?

  Personal laptop?

Worrying about such an obscure, time consuming hack probably isn't worth your time. There are far more effective ways to get your data.

----------

## ulenrich

Question to a physics expert:

Is this rowhammer effect due to higher probabilities of tunnel effects at the nano scale?

Someone once said to me: By the law of quantum physics you as a human being might well go through a massively built stone wall. It is just a matter of tries (big number of tries). As you shrink yourself the number of tries needed will shrink exponentially.

Is this rowhammer effect naturally growing in times the processors are shrinking? Thus a more fundamental flaw of information technology our times. Only as a side effect a security problem?

----------

## The Doctor

 *ulenrich wrote:*   

> Question to a physics expert:
> 
> Is this rowhammer effect due to higher probabilities of tunnel effects at the nano scale?
> 
> Someone once said to me: By the law of quantum physics you as a human being might well go through a massively built stone wall. It is just a matter of tries (big number of tries). As you shrink yourself the number of tries needed will shrink exponentially.
> ...

 

Sorry, wrong type of physicist. I've always stayed as far away from solid state physics as possible.

It doesn't seem to be a universal problem which means it is more likely due to a design flaw. A big factor in newer chip design (as in, 6-7 years old) is that the miniaturization and higher clock speeds can literally turn a circuit board into a transmitter. Clearly, this is a major issue. The most likely explanation I can think of is that the rowhammer heats up a particular circuit and turns it into a transmitter which makes the other memory addresses act as a receiver and act on the instructions rather than a tunneling probability. If it was a tunneling problem I would expect it to be always present and the result would simply be a bad chip.

----------

## NeddySeagoon

Bit flips in DRAM is not a new phenomena.

Hands up if you remember the alpha particle induced bit flips.

/me raises hand.

----------

## John R. Graham

Ah, yes. The enemy within.

/me raises hand, too.

- John

----------

## ulenrich

 *The Doctor wrote:*   

> It doesn't seem to be a universal problem which means it is more likely due to a design flaw. A big factor in newer chip design (as in, 6-7 years old) is that the miniaturization and higher clock speeds can literally turn a circuit board into a transmitter. Clearly, this is a major issue. The most likely explanation I can think of is that the rowhammer heats up a particular circuit and turns it into a transmitter which makes the other memory addresses act as a receiver and act on the instructions rather than a tunneling probability. If it was a tunneling problem I would expect it to be always present and the result would simply be a bad chip.

 

Thanx for that more reasonable explanation!

----------

## e3k

 *Voltago wrote:*   

> Basically that you're probably going to be fine if you don't allow people to gain access to your machine ...

 

 *NeddySeagoon wrote:*   

> Don't let strangers in and don't run Java from dubious websites.

 

I consider the account running the browser as unsafe despite the fact i have the latest browser and noscript installed.

 *NeddySeagoon wrote:*   

> Decreasing the refresh period from 64ms to 32ms may mitigate the problem but without making it go away entirely.
> 
> If you know how to program the memory controller, the kernel can do that. 
> 
> 

 

I was hoping for a nice command for this but not regarding the mem allocation but for the heavy IO on RAM. not sure if it exists.

 *The Doctor wrote:*   

> Personal laptop?
> 
> Worrying about such an obscure, time consuming hack probably isn't worth your time. There are far more effective ways to get your data.

 

Personal desktop. It is obscure but for me it is very familiar to the RC4 WEP statistical attack like in aircrack-ng thats why i am talking about it.

I do not want to buy now new RAM or motherboard as i do not need it and mother earth has only limited resources. But i do not want to have a spam server + a bitcoin miner installed to slow down my machine and network.

----------

## NeddySeagoon

e3k,

To intsall a rowhammer program, the attacker first has to get in.

Do not run any services you don't need to minimise the attack surface.

Run a paranoid firewall, with policy 'drop' everywhere.  This will help to stop the nasties phoning home if they do get in.

If you have ECC RAM enable the ECC.  One bit errors will be detected and corrected. Two bit error will be detected but not corrected. The process will be killed.

With three and more bit errors, its harder to predict what happens.

----------

## e3k

 *NeddySeagoon wrote:*   

> e3k,
> 
> To intsall a rowhammer program, the attacker first has to get in.
> 
> With three and more bit errors, its harder to predict what happens.

 

yes i know the attacker has to get in but. with the current state of the web it is very easy to get in when you just use the browser. and no script is not an answer. the browsers today are just to complicated to be safe... and thanks for the how is ECC working introduction. When i need to update my pc it will be ECC for sure.

----------

## John R. Graham

 *ulenrich wrote:*   

> ...Is this rowhammer effect due to higher probabilities of tunnel effects at the nano scale? ...

 The original scholarly paper is an interesting read. The researchers don't actually do the work on the implementation level to determine the exact mechanism but they include some well reasoned speculation, the most likely of which appears to be electromagnetic coupling between adjacent row lines causing partial or momentary activation of the row transistors in adjacent rows, resulting in charge cell drainage. So, probably not.

 *The Doctor wrote:*   

> ...The most likely explanation I can think of is that the rowhammer heats up a particular circuit and turns it into a transmitter which makes the other memory addresses act as a receiver and act on the instructions rather than a tunneling probability. If it was a tunneling problem I would expect it to be always present and the result would simply be a bad chip.

 Got it in one.  :Wink: 

- John

----------

## krinn

As it is base on electric disturbance cause by proximity, you can move ram away from each other (if your bank aren't all fill)

You can remove memory

And you can use shielded ram (the one overclocker loves, that have shield to protect them from heating, in this case, it should also protect them from it)

But imo, you can even invite strangers wearing shades and black hat to your house, as it's something to let them swap bit, it's something different to actually use this to do something useful and the ones able to do that are fewer than you think, and they shouldn't wear black hat but some kind of white blouses  :Wink: 

Because even if you invite one guy that is known able to do it, the next question would be: what your computer hold that would be worth the effort?

I would say i would kindly invite such kind of guy to my house to get a coffee, as discussion with him should be a real good one.

----------

## e3k

 *krinn wrote:*   

> As it is base on electric disturbance cause by proximity, you can move ram away from each other (if your bank aren't all fill)
> 
> You can remove memory
> 
> And you can use shielded ram (the one overclocker loves, that have shield to protect them from heating, in this case, it should also protect them from it)
> ...

 

i am trying to explain it the whole thread. it is nothing special about this computer but the skynet bitcoin spam and ddos ultrabot does not care which machine it takes to do its business.

----------

## John R. Graham

 *krinn wrote:*   

> As it is base on electric disturbance cause by proximity, you can move ram away from each other (if your bank aren't all fill)
> 
> You can remove memory
> 
> And you can use shielded ram (the one overclocker loves, that have shield to protect them from heating, in this case, it should also protect them from it)

 krinn, the row lines are on the RAM chips themselves. The interference is between adjacent row lines on the same chip. Moving DIMMs around doesn't help, nor does external shielding.

- John

----------

## haarp

 *NeddySeagoon wrote:*   

> Two bit error will be detected but not corrected. The process will be killed.

 

In my experience, the mainboard just opts to hard-reset the entire machine instead.

----------

## kernelOfTruth

There's currently a discussion (or more) going on over at linux-kernel mailing list:

http://marc.info/?l=linux-mm&m=142666744515825&w=2

----------

## depontius

I my day job, I've spent some 30+ years in DRAM development, the last 15 years embedded, and standalone before that.  Back in my standalone DRAM days, we had patterns to specifically test for "row disturb", including hammering on the neighboring wordlines for a few thousand times.  Of course that was way back in the ancient days of about one-third micron, and we're more than an order of magnitude smaller than that now.

Seems to me that most of the time, the cache itself ought to mitigate this, because if you're hitting an address this frequently it should wind up in the cache and stay there.  I haven't actually read the reports to see how they're getting around that.  Of course root could, with exact knowledge of the CPU chip, but that makes it a different level exploit.

----------

## kernelOfTruth

There's already a patch in Linus' tree to prevent access to /proc/PID/pagemap

for non-root users:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=ab676b7d6fbf4b294bf198fb27ade5b0e865c7ce

"I fucking love opensource"   :Laughing: 

----------

## John R. Graham

 *depontius wrote:*   

> Seems to me that most of the time, the cache itself ought to mitigate this, because if you're hitting an address this frequently it should wind up in the cache and stay there.  I haven't actually read the reports to see how they're getting around that.  Of course root could, with exact knowledge of the CPU chip, but that makes it a different level exploit.

 There are machine instructions to force cache to be written to main memory. This is necessary in other contexts, for instance ensuring that all cached data is flushed to memory before doing DMA-based I/O (which operates on main memory directly).

- John

----------

## depontius

 *John R. Graham wrote:*   

>  *depontius wrote:*   Seems to me that most of the time, the cache itself ought to mitigate this, because if you're hitting an address this frequently it should wind up in the cache and stay there.  I haven't actually read the reports to see how they're getting around that.  Of course root could, with exact knowledge of the CPU chip, but that makes it a different level exploit. There are machine instructions to force cache to be written to main memory. This is necessary in other contexts, for instance ensuring that all cached data is flushed to memory before doing DMA-based I/O (which operates on main memory directly).

 

Can those instructions be used without being root?  Seems like a DOS opportunity to me, even without rowhammer, if it is so.

----------

## John R. Graham

Yes. There are many other usage scenarios where their unprivileged use makes sense. For instance to ensure consistency in memory shared between threads within the same process which, of course, may run on different cores.

- John

----------

