The researchers were also able to flip the bits inside DDR3 DIMMs installed on an enterprise-grade server. The tests succeeded even though all of the DDR3 modules included a protection known as ECC, the servers completely locked up or spontaneously rebooted, usually within three minutes of the tests commencing.
The system then goes merrily along and either crashes (because you've flipped some bits at random) or recovers (because those bits weren't important) or hands the attacker root (because you've managed to flip some particular target bits).
So if the computer crashes or locks up, you can probably conclude that you've defeated the ECC and flipped some bits, and the system is vulnerable to Rowhammer. It's (maybe) just a matter of time before someone engineers a way to flip the specific bits needed to hand the attacker root.
Even when trying to trigger rowhammer, the graph of bit flips is going to look like a logarithmic curve - Single-bit flips will be common, two-bits will be rare, and undetected flips will be real but ultimately not much to talk about compared to the discovered flips. You know they're there by the unrecoverable rate, and you replace the ram, discard any replicated data on that machine, and move on.
I don't have personal experience here, but one of the important claims in the paper is that this warning is not given on all servers:
Unfortunately, server vendors routinely use a technique
called ECC threshold or the 'leaky bucket' algorithm where
they count ECC errors for a period of time and report them
only if they reach certain levels of failure. From what we
understand, this threshold is commonly above 100 per hour,
but this remains a trade secret and varies based on the
server vendor. So, to see ECC errors (MCE in Linux or
WHEA in Windows), there generally needs to be 100 bit flips
per hour or greater. This makes “seeing” Rowhammer on
server error logs more difficult.
In addition, we have observed some server vendors will
NEVER report ECC events back to the OS,although they might
get logged into IPMI. Typically, users expect to see
correctable ECC errors logged directly to the OS or that
halt the system when they cannot be corrected. During our
investigation into this phenomenon, we even encountered one
server that neither reported ECC events to the OS nor
halted when bit flips were not correctable. The end result
was data corruption at the application level.
This is something, in our opinion, that should never happen
on an ECC protected server system.
ECC can normally detect and correct a single bit flip, and detect but not correct a double bit flip, in the "line" of bits protected by it. The ECC protection is local, not global; if there are many flipped bits but they are far enough from each other, each "line" will only have a correctable single-bit flip.
Does the paper claim that in fact triple bit flips are sufficiently more frequent than one would expect, and thus an exploitable security issue still exists with ECC? This would be interesting news. But if you are defining "attack" to include denial-of-service by crashing the machine, I presume the disagreement is only about terminology.
In general, if the ECC infrastructure works (e.g. DRAM detecting bit corruption and reporting it to the OS), the odds of an attacker finding a piece of RAM that flips bits "just right" to bypass the checksumming without triggering a OS panic are low enough that I'd rather worry about software bugs.
DoS may still be a pretty viable attack, though.