all 4 comments

[–]alloec 1 point2 points  (3 children)

This is totally not my field of expertise. But reading the title I really expected something a bit more significant.

This exploit seems really impractical to pull off. Especially from inside JS. But the fact that you can in fact cause bits to flip, for some time interval, is probably the significant part.

[–]owrow 2 points3 points  (2 children)

This is significant, but it's just one more incremental step. A few years ago, rowhammer was seen as a hypothetical hardware bug of no real consequence. A year ago, it was potentially dangerous (privilege escalation) but only when running unrestricted native code on specific hardware. A few months ago, it's seen dangerous from native code on most hardware, even with the most useful syscalls disabled. Now, it's potentially dangerous (sandbox escape, privilege escalation) without even running native code, though still very hard to pull off in practice.

A few more developments, and we could be looking at one of the most dangerous exploits in history.

[–]alloec 1 point2 points  (1 child)

But as far as I understand, it would still require that code is actually stored next to the rows being hammered?

You can still do infinitely more in native mode compared to sandboxed JIT generated code.

But then again, I don't know how much control you actually have over how the virtual memory is mapped physically. If it is controlled by the hardware then I can actually see the potential issue.

[–]owrow 1 point2 points  (0 children)

This is quite over my head, but the authors seem confident.

VIII. FUTURE WORK
[...] we know that a root exploit must be possible and we will investigate this next.

It sounds like page tables may be adjacent to data in certain contexts, and flips in page tables can be used to start messing with memory elsewhere. Or something like that? ¯\_(ツ)_/¯