Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Security

Rowhammer Attacks Can Now Bypass ECC Memory Protections (zdnet.com) 67

Catalin Cimpanu, reporting for ZDNet: Academics from the Vrije University in Amsterdam, Holland, have published a research paper this week describing a new variation of the Rowhammer attack. For readers unfamiliar with the term, Rowhammer is the name of a class of exploits that takes advantage of a hardware design flaw in modern memory cards. By default, a memory card stores temporary data inside storage units named cells, which are arranged on the physical silicon chip in multiple rows, in the form of a grid. [...] In research [PDF] published today, named ECCploit, academics expanded the previous Rowhammer techniques with yet another variation. This one, they said, bypasses ECC memory, one of the memory protections that hardware makers said could detect and prevent Rowhammer attacks in the past.

ECC stands for Error-Correcting Code and is a type of memory storage included as a control mechanism with high-end RAM, typically deployed with expensive or mission-critical systems. ECC memory works by protecting against rogue bit flips, like the ones caused by Rowhammer attacks. Surprisingly, it wasn't developed to deal with Rowhammer. It was initially developed in the 90s to protect against bit flips caused by alpha particles, neutrons, or other cosmic rays, but when Rowhammer came out, it also proved to be effective against it, as well. But after spending months reverse engineering the designs of ECC memory, the Vrije University team discovered that this protection mechanism has its limits.

This discussion has been archived. No new comments can be posted.

Rowhammer Attacks Can Now Bypass ECC Memory Protections

Comments Filter:
  • by Anonymous Coward on Saturday November 24, 2018 @06:45AM (#57692106)

    as being able to bypass ECC Memory Protections.

    It has been possible all along, it is just that someone has publicly proved that the theoretical vulnerability is an actual vulnerability. VERY important difference from title, since this could have allowed the compromise of servers since DDR3 came out and maybe even further back (although the glitches allowing this were only proven in certain brands of DDR3 early on. I have not heard whether it is now ALL DDR3, or still only certain DDR3 lithography processes.

    Assumed DDR4 is also compromised until you hear otherwise, and for anything that needs security, only run buffered ram, which is believed resistant if not immune to the attack.

    • by Anonymous Coward

      Why would buffered be resistant ?

    • by Anonymous Coward on Saturday November 24, 2018 @07:46AM (#57692212)

      The thing is, you should find your log full of correctable ECC errors and system panics because of uncorrectable errors if someone tries Rowhammer on you. The likelyhood for 1Bit-flips and 2Bit-flips is a lot higher than for 3Bit-flips.

      Both, especially the system panics, should be noticed by the users or your system monitoring.

      And DDR4 RAM has mitigation built in, called Target-Row-Refresh (TRR), which, when used, counts accesses to the neighbouring rows and if they exceed a threshold, refreshes the row. The question is, does the current hardware use it?

    • I have a very vague notion about how row hammer operates but it's really vague. COuld someone explain it both in terms of how it works, how one gets sidechannel information from being able to flip the bits, and then, pratically, how one makes a nefarious use out of spotty info.

      • Basic rowhammer:
        Step 1: Run some code 10,000 times until it works once
        Step 2: Publish

        The way you get sidechannel information specifically is:
        Step 1: Know what sidechannel information you want to get
        Step 2: Run some code 10,000,000 times until your buffer equals the data you wanted
        Step 3: Publish

        The point of this is not that somebody can extract useful sidechannel data in a realworld scenario. The point is merely that if you server is randomly crashing with lots of ECC errors in the logs, and the BIOS memory

    • No, not an "actual vulnerability," just an "actual example where the technique worked."

      Not really the same thing.

    • Isssue is by the time you have managed to produce a 3 bit error, you would have produced dozens of 1 and 2 bit errors and my monitoring system would begoing berserk and I would be investigating what the hell was going on. That is just a University HPC facility and any sort of ECC error is sufficiently rare as to be worth investigating as it is invariably a dodgy DIMM or node.

      I presume any monitored compute service would be the same. As such chances of this being used in the real world are likely to

  • Randomisation (Score:5, Interesting)

    by dohzer ( 867770 ) on Saturday November 24, 2018 @07:30AM (#57692170)

    Doesn't Address Space Layout Randomisation basically make this impractical?

    https://en.wikipedia.org/wiki/... [wikipedia.org]

  • The fact that servers normally utilize ECC RAM is probably the main reason this didn't blow up into a Spectre-style fiasco. I expect plenty of scrambling, in addition to slowdowns in VMs attempting to detect Rowhammer exploits. Rowhammer resistance for DRAM might be developed now, just like how Spectre resistance was a bullet point for the latest Intel CPUs, which is good since consumer devices were left vulnerable to Rowhammer.

    • by Anonymous Coward

      Unregistered ECC is basically only ever used on consumer grade chips. Registered memory is supported on anything server grade, and is usually cheaper than unregistered for the same capacity.

      The concern here is it means systems that DO support unregistered ECC, specifically AMD 939-AM4 systems and 115x series Xeons/Pentiums are now proven susceptible to rowhammer attacks, which means unless you keep them isolated from the possibility of exploits or running unverified remote code (like javascript), they can b

    • There is absolutely no reason why you would need to slow down the general VM to detect this. Unlike Spectre, which has to be actively prevented, this merely needs to be monitored and mitigated. You don't need the checks to stand in the way of access, they merely stand to the side and observe usage patterns and slow down access in certain scenarios. You wouldn't even need to reduce throughput noticeably.

      Unlike spectre which is a real threat in the datacenter, this is merely a thing that is worth watching.

  • row hammer being possible means memory has a bad design. any and all patterns should be able to be changed as quickly as possible in ram without affecting adjacent positions. the compromises made to make row hammer possible are due to incompetence, compromises were made that make a design unreliable

  • Was always curious why rowhammer still works after scramblers built into current day memory controllers. They explain some of the reason it still works on page 10.

    S|TME (total memory encryption) should be completely effective against these types of problems in future hardware.

Keep up the good work! But please don't ask me to help.

Working...