
Another Flip in the Wall of Rowhammer Defenses - et1337
https://arxiv.org/abs/1710.00551
======
jimrandomh
RowHammer is a category of security vulnerabilities that work by exploiting
DRAM that suffers from bit-flips when accessed in particular patterns. It can
be used for local privilege escalation; for example a cell-phone app without
permissions could use it to take full control of the phone, a server on a
shared cloud host could attack other sites on the same host, or in the worst
case, a browser Javascript program could break out of the browser (not done in
this paper, but done as a proof-of-concept with caveats in one of the papers
it cites). The main finding of this paper is that none of the existing
mitigations is fully adequate, not even ECC.

On the plus side, using RowHammers to make a fully working exploits is much
harder than most other types of exploits, and the exploits people have managed
to make so far have all involved major caveats (like requiring hundreds of
hours of full CPU usage to work, or providing memory layout information that
would be difficult for attackers to obtain). Still, the fact that this class
of exploit has proven so difficult to fully fix is worrying.

There's a section of proposed mitigations at the end, one of which sounds
particularly promising, though:

> "Kim et al. [38] and Kim et al. [37] proposed to eliminate bit flips in
> hardware by probabilistically opening adjacent or non-adjacent rows,
> whenever a row is opened or closed. As an ongoing Rowhammer attack would
> open and close a certain row repeatedly, the vulnerable adjacent rows would
> be refreshed before bit flips occur. We consider their approaches as a
> possible solutions to mitigate Rowhammer attacks in the future."

~~~
StillBored
I sure would like to know how ECC fails to alleviate this. People forget that
the standard single bit correction, double bit detection really means,
guaranteed single bit correction, and guaranteed double bit detection with a
probability of detecting > 2 bits depending on how/where they flip.

~~~
cryptonector
TFA said nothing about ECC failing to stop RowHammer. TFA does discuss the
cost of ECC (or ChipKill) and the fact that Intel does not even support ECC on
consumer kit -- i.e., ECC's availability is rather limited.

~~~
StillBored
to quote TFA.

"ECC RAM can detect and correct 1-bit errors and, thus, deal with single bit
flips caused by the Rowhammer attack. Furthermore, IBM’s Chipkill error
correction [27] allows to successfully recover from 3-bit errors. However,
uncorrectable multi-bit flips can be exploitable [2, 3, 42] "

Maybe that, combined with a lot of weasel words about the effectiveness of ECC
muddy the water.

~~~
cryptonector
But they did not actually demonstrate any attacks on ECC.

------
tlb
Software mitigation is not the right way to deal with RAM that can be fooled
into flipping bits. All DRAM with this vulnerability should be recalled as
defective. We'd certainly demand that Intel fix a vulnerability that let you
flip register bits in other processes by doing something you can do from
Javascript.

There are reasonable defenses possible inside the DRAM. They currently depend
on the fact that repeated reads of the same data are rare, because of caches.
DRAM should insert a delay after hitting the same row N times between
refreshes, depending on its analog parameters. It won't affect performance in
any normal application.

~~~
rasz
You can also work around it in memory controller incorporating row access
counters and forcing refresh after X accesses.

~~~
tlb
The memory controller may be a more efficient place to do it, because the
silicon process is better suited to logic. The challenge is agreeing on how to
specify limits on access patterns. JEDEC would have to define a protocol for
the memory chips to inform the controller of how many accesses per row are
allowed between refreshes.

~~~
rasz
target row refresh (TRR) is already a thing in laptop DDR4 and is being
reported as part of SPD, but it appears Intel still doesnt support it (Cisco
claimed Intel does support it, but its hard to believe them when Intel itself
never claimed it publicly)

------
peoplewindow
_Finally, we abuse Intel SGX to hide the attack entirely from the user and the
operating system, making any inspection or detection of the attack infeasible_

It's unfortunate that academics feel OK about making misleading statements in
this space. SGX enclaves must be signed by Intel to work, so I doubt very much
that they abused SGX in this way. What they mean is that they _could_ have
done, _if_ they had got Intel to approve their attack, which is a pretty
freaking huge caveat.

~~~
ameliaquining
No, the attack doesn't require Intel to sign the attacker's code. It works by
abusing SGX's tamper detection, which hangs the machine if a forbidden memory
region has been written to. If you can trigger such forbidden writes
repeatedly (which is what Rowhammer does), you can DDoS a cloud provider.

~~~
peoplewindow
The paper makes several claims about SGX, but the part I quoted says it uses
it to hide the attack from the operating system. The "DoS a cloud by making a
hang" aspect is different.

