Slashdot Mirror

← Back to Stories (view on slashdot.org)

Exploiting the DRAM Rowhammer Bug To Gain Kernel Privileges

Posted by Soulskill on from the flipping-tables-over-flipped-bits dept.

New submitter netelder sends this excerpt from the Project Zero blog: '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 (PDF) to all of physical memory.

4 of 180 comments (clear)

  1. ECC Memory by Frobnicator · · Score: 5, Interesting

    Yet another reason to push shared providers for ECC memory. The error correcting memory is so far not vulnerable to this attack, all the researchers that have tried it report that ECC memory identifies and corrects the corruptions. Of course some attackers may have found a way, but ECC minimizes the risk

    Amazon says it uses ECC in their AWS machines, but other big hosts like Equinix say that ECC memory is "available". Be careful about your hosting, folks.

    --
    //TODO: Think of witty sig statement
    1. Re: ECC Memory by Macman408 · · Score: 5, Interesting

      I hadn't heard of this either, but a quick google turned up a description of false parity RAM: http://en.wikipedia.org/wiki/R...
      TLazy;DR: To save cost where parity RAM was required by the hardware but not by the operator, modules existed that would calculate the parity bit upon reading the RAM, rather than storing the parity bit. I don't see any evidence that this type of module ever existed for ECC though.

      To make sure memory is ECC, it's probably sufficient to count the memory chips on a DIMM. If there are 9 or 18 (or even 36, if it's a particularly large DIMM) identically-marked chips, that's ECC. If there are 4, 8, 16, or 32 chips, then it's probably not. If one of the chips is marked differently than the others, it might be a little more complicated; it might be possible that it's a different memory chip (e.g. if there are 4 x16 memory chips, you'd only need one x8 to get a x72 ECC DIMM, so that last chip would be different). But it's also possible that it's buffered/registered memory, and the different chip is the buffer/register.

      And an aside on the topic of buying RAM for yourself:
      In general, I'm not a fan of cheaping out on memory. I did computer repair for a while, and it shocked me how many problems were caused by bad RAM - from the obvious ("my computer crashes every time I boot it") to less obvious ("every few days, an application crashes") to the rather insidious ("it was running fine, and now I can't mount my hard drive any more"). It got to the point where, when a computer came in with nonspecific symptoms like that, I'd open up the computer and peek at the RAM chips first. If they had no recognizable manufacturer, they were certainly garbage. If they were recognizable but not top-tier, they probably needed some stress testing on our RAM tester. And if they were the good stuff (Samsung always had my vote there, though it's hard to find because they don't sell directly to consumers), then it was probably something else.

      That's also where I learned that things like memtest86 or other software diagnostic tools were basically useless too. Only the absolute worst memory would fail a test, even a looped test run for days. Most bad RAM was marginal - after all, it probably passed some manufacturing tests. We had a rather expensive (~$4k-8k) box that would test memory, doing things like varying the supply voltage or self-heating the RAM. When RAM is installed in your PC, you're still limited by the hardware - i.e. the voltage regulator and the memory controller - which probably keep the memory as close to nominal conditions as possible. Obviously, those machines are rather hard to come by, so you have to make do with software tests instead - but a pass on those just means I can't prove it's bad; it doesn't mean the memory is good. Even if I pass all memory testing, I'll still swap/remove/replace DIMMs in an attempt to find which one is bad, because it's often not obvious.

  2. Deja vu... by sotweed · · Score: 5, Interesting

    This problem is remarkably similar to a problem I encountered in the memory of a 7094 (old
    IBM computer) which had a core memory which stored 36-bit words. The memory was supposed
    to work by operating on 6 bits at a time at 200 nanosecond intervals. The reason for this was to avoid
    creating a magnetic field that was too strong. The problem occurred when the timing was off due
    to failure of a component and two of the intervals overlapped. This meant that when one attempted
    to store a word with 35 1s, the field created was strong enough to store 36 1s. We wrote a
    diagnostic to demo the problem, and with that the engineers were able to isolate and fix the problem
    in short order.

    1. Re:Deja vu... by sotweed · · Score: 5, Interesting

      I was describing something that happened in a machine that was built before the world settled
      on 8-bit bytes. The machine had 36-bit words, and each word had an address. The 6-bit
      nibbles were not addressable. It was 32,768 (2**15) words of 36 bits. Equivalent
      to a little over 100K bytes!