"Exploiting the DRAM rowhammer bug to gain kernel privileges "

“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.
(...)
This works because DRAM cells have been getting smaller and closer together. As DRAM manufacturing scales down chip features to smaller physical dimensions, to fit more memory capacity onto a chip, it has become harder to prevent DRAM cells from interacting electrically with each other. As a result, accessing one location in memory can disturb neighbouring locations, causing charge to leak into or out of neighbouring cells. With enough accesses, this can change a cell’s value from 1 to 0 or vice versa."

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

 

http://www.infoworld.com/article/28...bug-threatens-to-smash-notebook-security.html

 

Ouch ouch ouch. Good reminder of why software security people need to remember how hardware works.

 

http://blog.erratasec.com/2015/03/some-notes-on-dram-rowhammer.html

 

Wow, so they leveraged HW structure (proximity to next row) for exploit!

 

As far as i can determine, the correct Ones & Zeros bit/s would need to infuence the Exact requried Ones & Zeros bit/s in the adjoining row/s. So how do they know what's there already to do that ? Just 1 wrong bit & it wouldn't work properly

 

http://www.infoworld.com/article/29...hing-webbased-attack-on-a-computers-dram.html

 

If you have an AMD processor, no worry. If you have an Intel processor, your 16K - 23K times more likely to have hammer memory issues.

http://users.ece.cmu.edu/~omutlu/pub/dram-row-hammer_kim_talk_isca14.pdf

 

Reduce your refresh rate - that should do the trick:

Anyway, here's a 3 May 15 Update:

Finally achieved stability

I finally managed to determine a RAM setting that can consistently pass the Memtest86 row hammer test. As you can see from this image, I ran just test 13 for 5 hours and 40 minutes. It passed all 14 tests this time.

Click this bar to view the full image. The original image is sized 1200x369 and weights 204KB.
http://forum.corsair.com/v3/attachment.php?attachmentid=21658&stc=1&d=1430652196

I had to reduce the DRAM Refresh Interval drastically, from 5200 to 3000 to achieve 100% Memtest86 stability. This represents a 43% decrease in the time elapsed before the next refresh command is given.

The duration of each refresh cycle (measured by the "Refresh Cycle time"), on the other hand, seemed to have done little to impact stability. I say "seemed to have" because increasing this value didn't eradicate the errors and decreasing this value didn't harm stability either. But without conducting a rigorous and VERY time-consuming experiment, I cannot be sure.

Digging deeper into the performance impact

So the next question you might have is this (at least I did): what is the performance penalty incurred from having to almost double the refresh frequency of the RAM?

To investigate, I ran 2 synthetic benchmarks, IntelBurnTest v2.54 by AgentGod and Realbench v2.4 by ASUS. I chose these 2 tests because a) they both produce a result which can easily be compared (unlike Prime95 benchmark) and b) IntelBurnTest should be able to tease out any performance differences given how compute intensive it is, while Realbench would be able to more accurately demonstrate the performance impact on everyday tasks. I may consider running PCmark 8 if there's a request to.

For IntelBurnTest, I ran the test 10 times and set the RAM utilisation to 4096MB. I then took the most often occurring GFlops (IE, the mode) and rounded it to 1 dp.
For Realbench, I ran the benchmark 5 times. Again, I took the most often occurring System Score and rounded it to 3 sf.

Here are the results of the test, after decreasing the refresh interval from 5200 to 3000.

IntelBurnTest: 112.6 to 113.1 (not sure what went wrong here)
Realbench: 74100 to 73500

Conclusion: There is no performance difference that can be observed from the tests, which is good news because it means I achieved stability seemingly without having to sacrifice performance

 

Once thought safe, DDR4 memory shown to be vulnerable to “Rowhammer”

-- Tom

 

DRAM bitflipping exploits that hijack computers just got easier

http://arstechnica.com/security/201...ploits-that-hijack-computers-just-got-easier/

 

New FFS Rowhammer Attack Hijacks Linux VMs

http://news.softpedia.com/news/new-ffs-rowhammer-attack-targets-linux-vm-setups-507290.shtml

 

New cloud attack takes full control of virtual machines with little effort

http://arstechnica.com/security/201...o-keys-by-corrupting-data-in-computer-memory/

 

Forget Software—Now Hackers Are Exploiting Physics

-- Tom

 

Using Rowhammer bitflips to root Android phones is now a thing

http://arstechnica.com/security/201...tflips-to-root-android-phones-is-now-a-thing/

 

Elegant Physics (and Some Down and Dirty Linux Tricks) Threaten Android Phones

-- Tom

 

Hardware Bit-Flipping Attacks in Practice by Bruce Schneier

-- Tom

 

https://www.theregister.co.uk/2017/08/17/rowhammer_for_nand_flash/

 

Wow... Over my head in the end, but I don't understand this part at all:

 

Encrypting data when written to disk probably breaks an attack. It's another layer between flash and OS and they probably can't control it.

 

Hmm, but how much of a layer is it when browser/OS is running and data decrypted on-the-fly?

 

Since they are manipulating on how data is written on really low level, additional encryption process might be a big problem.
This is just my assumption, of course.

 

Packets over LAN are all it takes to trigger serious Rowhammer bit flips

https://arstechnica.com/information...-flips-by-sending-network-packets-over-a-lan/

 

Nethammer – Exploiting Rowhammer attack through network without a single attacker-controlled line of code
May 17, 2018
https://securityaffairs.co/wordpress/72624/hacking/nethammer-rowhammer-attack.html

 

Every Android Device Since 2012 Impacted by RAMpage Vulnerability
June 28, 2018
https://www.bleepingcomputer.com/ne...since-2012-impacted-by-rampage-vulnerability/

Research paper: https://vvdveen.com/publications/dimva2018.pdf