If you have a process running on your machine can it use this to get root? Read Keys?
It looks like they ran their process for 12 hours to do the flipping.
And if your flipping your process's memory for that long, what are the chances you are next to sensitive memory for another process? It seems bad, but it seems like if your randomly flipping bits in memory the system will likely crash.
Yes. There's a BlackHat talk on that[1]. DoS is a big issue on shared hardware too. You can crash other processes, the kernel and the hypervisor.
> And if your flipping your process's memory for that long, what are the chances you are next to sensitive memory for another process?
You don't need to leave it up to chance. There are apparently ways you can control it and of course you can just spray everything.
1. https://www.blackhat.com/docs/us-15/materials/us-15-Seaborn-...
2. https://github.com/google/rowhammer-test/blob/master/rowhamm...
My (probably slightly naive) understanding is the OS is allocating memory, acting like a memory cop so processes don't overlap and swapping when needed and so forth. It seems like these hardware errors might be mitigated by the OS.
I'm in a bit over my head in the pdf, but it explains: "Our kernel privilege escalation works by using row hammering to induce a bit flip in a page table entry (PTE) that causes the PTE to point to a physical page containing a page table of the attacking process. This gives the attacking process readwrite access to one of its own page tables, and hence to all of physical memory."
I'm still a little fuzzy on how they get the right location in the page table without hosing the system, but this gives me enough of a gist. Thanks!
You don't need to have access to the memory you want to attack, only the ability to cause something to read from memory that physically neighbors the memory you want to attack.
Think of page tables like a big array in kernel memory (I'm being imprecise.) The entries in this table are mappings from your virtual addresses to physical addresses. You can cause the kernel to read your at least part (or all of?) your PTEs, which means you can cause it to flip bits in neighboring physical cells, which means you can modify the PTEs. TL;DR: If you can cause the kernel to read some specific memory then you can modify memory near it. In this case, you can modify the page table entries, allocating memory that isn't yours to you (or doing other funny things.)
A simpler to explain but probably not realistic explanation: Imagine if your UID is stored right next to your GID in some kernel structure, if you could cause the kernel to repeatedly read your GID then you could cause bit flips in your UID, which would change which user your user...
Is there something I'm missing here? What are the realistic attacks that this vulnerability allows?
Which keys? OpenBSD / OpenSSH for example does now (since 2019?) encrypt SSH keys in RAM to prevent rowhammer like attacks. They're mixing the key with a huge "pre key" and an attacker would need to side-channel attack the entire pre key to be able to read the real SSH keys.
So it's not as if there was nothing that could be done to guard against this.
It may require changing lots of software/libraries but at least the security-conscious ones already started, without waiting for this "blacksmith" attack.