According to the article, no.

What I want to know is if this works on ECC memory. I'm guessing not, which makes the "vulnerability" even more of a non-issue in mission-critical applications that likely moved to ECC a while ago.

Yes, Rowhammer can bypass ECC. Forgot to include this in the article, mainly because there's so much Rowhammer research.

See here: https://www.vusec.net/projects/eccploit/

It's really worth noting that ECC does impact Rowhammer effectiveness, even if it is not enough to prevent the attack 100% of the time.

But as part of this it'll also have a high chance of triggering a system shutdown due to ECC mismatch, right? So in most cases it can't be exploited for things other than DoS.

ECC won't necessarily shut the system down as it can actually repair single bit errors, and mismatches can be monitored for as well. But your point stands - for an attacker to do damage they'll likely end up flipping bits in unintended ways first.

Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type? I don't think so. Why would someone have ECC without a sufficiently sophisticated driver?

> Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type?

Afaik, yes it can (unless you're counting HW_EVENT_ERR_CORRECTED). They specifically try to get 1 or 3 bit flips, never 2.

See here: https://www.vusec.net/projects/eccploit/

(yes, that's the same link)

> Can Rowhammer bypass ECC and not be detected by an hw_event_mc_err_type?

It's definitely possible in theory. You'd need four bit flips rather than three, so you'd probably need more time between accesses to the victim row, but thats a quantitative improvement at best. This can be mitigated by using different ECC bit encodings per memory location[0], so hammered data, with correct ECC for its row, always has wrong ECC values for the adjacent rows, but I don't think anyone does that.

0: This is important in order to make fake ECC memory, which uses a (cheap) combinatoric circuit in place of a (more expensive) ninth DRAM chip, not work, so it should be happening even without Rowhammer, but AFAIK it isn't.

We should be using memory encryption with random per-boot keys to prevent cold boot attacks, which would also solve the issue. Then the software doesn't know how its data maps to the encrypted data at the RAM. Rows may map 1:1, but you wouldn't know which bits you're targeting.

Good point. Although memory encryption is much more useful if applied at the CPU rather than the memory controler (which would need a way to turn encryption off for DMA regions, since the memory controller doesn't know the key), there's no actual reason why you couldn't do it in the memory controller, if you trust all the hardware with DMA access, or (more plausibly) trust the memory controller to limit that access properly.

> Why would someone have ECC without a sufficiently sophisticated driver?

Have you, personally, tested your servers to make sure the driver correctly handles bit errors? Can't say I have.

Last time I tested such things, they handled ECC correctly (x86 and arm).

Apparently it does but I haven't tested it myself

Wasn’t there a rowhammer based website for rooting android phones in the past?

Good question. what would the evidence be? memory errors? i wonder how easy to detect these would be

Is there any evidence it's not just a matter of time before there is?

Rowhammer, Spectre, etc. are all very high-information attacks which strike me as not worth the effort for run of the mill adversaries. Three-letter agencies, however, I suspect might have played around with them - if a cloud vendor is secure, and they need a way to un-secure it, they have the resources to get microarchitectural researchers sworn to secrecy to make these attacks work.

TBH I think right now it's more of an incentive thing. Consider that:

a) Attackers would have to develop the POC. This will require a somewhat different skillset than typical exploitation, so there's effort involved.

b) Rowhammer is best for privilege escalation. For desktop users (where the most money is) privesc is already pretty trivial - no need for fancy exploits, you can pretty much just ask for root or use a much more straightforward exploit.

c) Exploit devs don't typically like a lot of attention. You don't want to be the first person selling rowhammer exploits unless you can charge out the ass for it, because you're gonna get way more attention for it.

These incentives aren't super technical, they're mostly market driven, and it's why we don't see fancier attacks in practice, even if they're practical. As one attacker I know was saying to me, they wish they had an excuse to do the fancy thing, but it's never worth the investment when you can own boxes way more easily. Another hacker said "I don't want a Krebs article on me because I did something clever".

NSA's incentives are not super difference, except they're not as directly financial. They also have crazy resources to fuck around with this stuff, so it would make sense that they'd demo it in a lab. Would they actually deploy it? Eh, doubtful. Against another advanced defender rowhammer should be pretty detectable by monitoring ECC metrics, and again, why would you do something fancy when you can just buy 0days - the USG purchases hundreds a year from private companies and develops more themselves.

Rowhammer has been known of for over 5 years.

You don't need to have a practical attack for something to be a credible threat that needs to be addressed in a multi-tenant system (like say, cloud providers).