"Exploiting the DRAM rowhammer bug to gain kernel privileges "

Discussion in 'other security issues & news' started by ichito, Mar 9, 2015.

  1. ichito

    ichito Registered Member

    Joined:
    Jan 14, 2011
    Posts:
    1,485
    Location:
    Poland - Cracow
    “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
     
  2. Dermot7

    Dermot7 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    3,196
    Location:
    Surrey, England.
    http://www.infoworld.com/article/28...bug-threatens-to-smash-notebook-security.html
     
  3. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,459
    Ouch ouch ouch. Good reminder of why software security people need to remember how hardware works.
     
  4. Dermot7

    Dermot7 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    3,196
    Location:
    Surrey, England.
  5. Yuki2718

    Yuki2718 Registered Member

    Joined:
    Aug 15, 2014
    Posts:
    1,257
    Wow, so they leveraged HW structure (proximity to next row) for exploit!:eek:
     
  6. CloneRanger

    CloneRanger Registered Member

    Joined:
    Jan 4, 2006
    Posts:
    4,833
    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
     
  7. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,057
  8. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
  9. itman

    itman Registered Member

    Joined:
    Jun 22, 2010
    Posts:
    2,969
    Location:
    U.S.A.
    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
     
  10. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
  11. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,057
    DRAM bitflipping exploits that hijack computers just got easier
    http://arstechnica.com/security/201...ploits-that-hijack-computers-just-got-easier/
     
  12. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,057
  13. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,057
  14. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
    Forget Software—Now Hackers Are Exploiting Physics

    -- Tom
     
  15. Minimalist

    Minimalist Registered Member

    Joined:
    Jan 6, 2014
    Posts:
    5,057
  16. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
  17. lotuseclat79

    lotuseclat79 Registered Member

    Joined:
    Jun 16, 2005
    Posts:
    5,094
    Hardware Bit-Flipping Attacks in Practice by Bruce Schneier

    -- Tom
     
Loading...