Exploit for DRAM Found

[SIGSEGV]

Note: Please credit WereCat for OP if this goes on the WAN show, not me.

Like they say, if a hacker has hardware access you're screwed

http://arstechnica.com/security/2015/03/cutting-edge-hack-gives-super-user-status-by-exploiting-dram-weakness/

rest of old OP

The technique, outlined in a blog post published Monday

by Google's Project Zero security initiative, works by reversing individual bits of data stored in DDR3 chip modules known as DIMMs. Last year, scientists proved that such "bit flipping" could be accomplished

by repeatedly accessing small regions of memory, a feat that—like a magician who transforms a horse into a rabbit—allowed them to change the value of contents stored in computer memory. The research unveiled Monday showed how to fold such bit flipping into an actual attack.

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.

[Dabombinable]

Thank god I've got 8GB of DDR2 still.

[Mew]

So.......does that mean DDR3 RAM prices are gonna tank so I can buy an additional set of 16GB for really cheap?

[Dezz]

So.......does that mean DDR3 RAM prices are gonna tank so I can buy an additional set of 16GB for really cheap?

 

Any chance for fixing this?

[deviant88]

FAKE they want to make DDR3 to seem weak,in order to make DDR4 relevant since its mostly useless.And this is aimed at servers cause who cares about desktop users.

 

[Dabombinable]

FAKE they want to make DDR3 to seem weak,in order to make DDR4 relevant since its mostly useless.And this is aimed at servers cause who cares about desktop users.

 

Either way, it won't affect me-once I get my new qx extreme and mobo, my i5 4440 gets its early retirement.

[Tonylu1595]

Hey, anyone have some DDR2 laying around?

[Dabombinable]

Hey, anyone have some DDR2 laying around?

Derp 

[VerticalDiscussions]

Bah unless i hand them over my sticks of RAM the only thing they can do is cry to "physically" steal data.

[TheMidnightNarwhal]

Is this virtually or physically achieveable?

[asim1999]

Good thing i have DDR4