DRAM bug - Rowhammer

[WereCat]

If repost sorry. I was looking but didnt found it in here.

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

 

I strongly recommend reading the article for those who are interested as it is a bit complex so I will quote only some things.

 

 

 

“Rowhammer” is a problem with some recent DRAM devices in which repeatedly accessing a row of memory can cause bit flips in adjacent rows. We tested a selection of laptops and found that a subset of them exhibited the problem. We built two working privilege escalation exploits that use this effect. One exploit uses rowhammer-induced bit flips to gain kernel privileges on x86-64 Linux when run as an unprivileged userland process. When run on a machine vulnerable to the rowhammer problem, the process was able to induce bit flips in page table entries (PTEs). It was able to use this to gain write access to its own page table, and hence gain read-write access to all of physical memory.

 

We don’t know for sure how many machines are vulnerable to this attack, or how many existing vulnerable machines are fixable. Our exploit uses the x86 CLFLUSH instruction to generate many accesses to the underlying DRAM, but other techniques might work on non-x86 systems too.

 

We expect our PTE-based exploit could be made to work on other operating systems; it is not inherently Linux-specific. Causing bit flips in PTEs is just one avenue of exploitation; other avenues for exploiting bit flips can be practical too. Our other exploit demonstrates this by escaping from the Native Client sandbox.

 

Basicaly they are saying that by using this exploit someone can get your root access in your OS. Google managed to change bits in 15 out of 29 notebooks. How many devices is affected is unknown.

 

The paper explains that this tiny snippet of code can cause bit flips:

 

code1a:

  mov (X), %eax  // Read from address X

  mov (Y), %ebx  // Read from address Y

  clflush (X)  // Flush cache for address X

  clflush (Y)  // Flush cache for address Y

  jmp code1a

 

Two ingredients are required for this routine to cause bit flips:

 

Address selection: For code1a to cause bit flips, addresses X and Y must map to different rows of DRAM in the same bank.

 

Some background: Each DRAM chip contains many rows of cells. Accessing a byte in memory involves transferring data from the row into the chip’s “row buffer” (discharging the row’s cells in the process), reading or writing the row buffer’s contents, and then copying the row buffer’s contents back to the original row’s cells (recharging the cells).

 

It is this process of “activating” a row (discharging and recharging it) that can disturb adjacent rows. If this is done enough times, in between automatic refreshes of the adjacent rows (which usually occur every 64ms), this can cause bit flips in the adjacent rows.

 

The row buffer acts as a cache, so if addresses X and Y point to the same row, then code1a will just read from the row buffer without activating the row repeatedly.

 

Furthermore, each bank of DRAM has its own notion of a “currently activated row”. So if addresses X and Y point to different banks, code1a will just read from those banks’ row buffers without activating rows repeatedly. (Banks are groups of DRAM chips whose rows are activated in lockstep.)

 

However, if X and Y point to different rows in the same bank, code1a will cause X and Y’s rows to be repeatedly activated. This is termed “row hammering”.

 

Bypassing the cache: Without code1a’s CLFLUSH instructions, the memory reads (MOVs) will be served from the CPU’s cache. Flushing the cache using CLFLUSH forces the memory accesses to be sent to the underlying DRAM, which is necessary to cause the rows to be repeatedly activated.

 

Note that the paper’s version of code1a also includes an MFENCE instruction. However, we found that using MFENCE was unnecessary and actually reduced the number of bit flips we saw. Yoongu Kim’s modified memtest also omits the MFENCE from its row hammering code.

 

Testing your own machine

Users may wish to test their own machines using the rowhammer-test tool above. If a machine produces bit flips during testing, users may wish to adjust security and trust decisions regarding the machine accordingly.

 

While an absence of bit flips during testing on a given machine does not automatically imply safety, it does provide some baseline assurance that causing bit flips is at least difficult on that machine.

This is prety major bug. It is surprising that it was not noticed sooner and I dont think it will be resolved soon. I would like to add more to this but I am not really into these things and understand only core of it.

[snowComet]

repost??

http://linustechtips.com/main/topic/325485-exploit-for-dram-found/

[cesrai]

I wonder how much work and effort got into this.

[WereCat]

repost??

http://linustechtips.com/main/topic/325485-exploit-for-dram-found/

Yea... Damn.

I tried to google Rowhammer and RAM bug and even looked quickly trough News but havent seen it.

[cesrai]

repost??

http://linustechtips.com/main/topic/325485-exploit-for-dram-found/

I like this post more than the other.

[Geekazoid]

repost??

http://linustechtips.com/main/topic/325485-exploit-for-dram-found/

Oh! Don't you just love it when you can type that very demeaning word "repost"? Makes you feel so happy like "Ha! It's already been posted here you idiot!". Now, that's not how I think, but I'm betting that's what you were thinking when you posted that, weren't ya?

[Geekazoid]

I like this post more than the other.

Agreed!

[snowComet]

Oh! Don't you just love it when you can type that very demeaning word "repost"? Makes you feel so happy like "Ha! It's already been posted here you idiot!". Now, that's not how I think, but I'm betting that's what you were thinking when you posted that, weren't ya?

 

I know the issue.I just tell him that had been posted, and I didn't report it.

And I didn't act like the way you described me, I don't think he is an idiot or anything similar. I do like his post, but I do think it is necessary to tell him that it has been posted before...

 

I do report those badly written posts, but I didn't report any that are well written...

maybe I should tell them in private messages next time

 

[Geekazoid]

I know the issue.I just tell him that had been posted, and I didn't report it.

And I didn't act like the way you described me, I don't think he is an idiot or anything similar. I do like his post, but I do think it is necessary to tell him that it has been posted before...

I recommend going to the other thread and whacking a "repost" there and giving a link to this thread.

[WereCat]

I know the issue.I just tell him that had been posted, and I didn't report it.

And I didn't act like the way you described me, I don't think he is an idiot or anything similar. I do like his post, but I do think it is necessary to tell him that it has been posted before...

 

I do report those badly written post, but I didn't report any that is well written...

maybe I should tell them in private messages next time

It is all right, no hard feelings I am prety often on the forum checking news but that one escaped from my glance.

[Trik'Stari]

Wait....so did I need to RMA that ram that was throwing errors during the hammer row test in memtest 86?

[snowComet]

I recommend going to the other thread and whacking a "repost" there and giving a link to this thread.

 

You can do that, but many will still do the same, nth will change...

that's why a while ago I have discussions with others on this matter. This is a problem happened long ago, and changes and rules are necessary regarding this matter...

[Geekazoid]

You can do that, but many will still do the same, nth will change...

that's why a while ago I have discussions with others on this matter. This is a problem happened long ago, and changes and rules are necessary regarding this matter...

I was being facetious (hence the ).

[snowComet]

I was being facetious (hence the ).

 

Maybe I'm too serious, but this issue has been bugging this subforum for a long time... 

and little success is achieved on tackling this issue...

I'm a little frustrated with this. I do hate seeing well written posts being locked, but somebody will call repost even if I don't do it...

[SIGSEGV]

Repost: http://linustechtips.com/main/topic/325485-exploit-for-dram-found

If you want I can merge the OP though

[Geekazoid]

Repost: http://linustechtips.com/main/topic/325485-exploit-for-dram-found

Really? :huh:

[snowComet]

Really? :huh:

 see :mellow: ~~

prove what I just said...

 

[SIGSEGV]

Really? :huh:

What?

[snowComet]

What?

 we are discussing whether a well written post should be locked just because somebody posted it before...

and you did what I just did a few posts ago...

[SIGSEGV]

we are discussing whether a well written post should be locked just because somebody posted it before...

and you did what I just did a few posts ago...

I can just copy and paste his post if he wants

[Geekazoid]

we are discussing whether a well written post should be locked just because somebody posted it before...

and you did what I just did a few posts ago...

Precisely.

[snowComet]

I can just copy and paste his post if he wants

I do think this is a better solution. And Pls credited OP for his work...

Thx!~~

[SIGSEGV]

I do think this is a better solution. And Pls credited OP for his work...

Thx!~~

Done

[WereCat]

Repost: http://linustechtips.com/main/topic/325485-exploit-for-dram-found

If you want I can merge the OP though

OK