4 ms·

This seems bad, but as a practical matter, what does this mean? If you have a process running on your machine can it use this to get root? Read Keys? It looks

This seems bad, but as a practical matter, what does this mean? 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.

ARandumGuy 5y ago
That's my question as well. I'm not a security expert, but this doesn't seem all that concerning for anything other then the highest security applications. It seems to me that executing this attack not only requires running code on the target machine (which admittedly isn't that big of a hurdle), but requires basically complete knowledge of memory allocation at the time of the attack, something that is fairly opaque and ever changing on most hardware. Is there something I'm missing here? What are the realistic attacks that this vulnerability allows?
- myself248 5y ago
  There's no reason the code couldn't just blindly try every attack until it finds one that succeeds. If there's a malicious app that runs a lot (lookin' at you, random firefox tab that eats 99% of my CPU for minutes at a time and then goes idle again), it has all the time in the world.
- pfortuny 5y ago
  See my reply above: in-memory data analysis…
- joebob42 5y ago
  It might be hard to do a targeted attack. On the other hand, flipping random bits is likely to just start crashing stuff and / or producing incorrect results pretty reliably.
- guerrilla 5y ago
  See my reply, sibling to yours.
- acuozzo 5y ago
  > What are the realistic attacks that this vulnerability allows? https://github.com/IAIK/rowhammerjs https://github.com/IAIK/rowhammerjs
pfortuny 5y ago
This may be very bad for data analysts. Imagine trying to study a huge in-memory database and getting different values each time…
- speedgoose 5y ago
  Assuming you run your database in a public cloud, what's the likelihood of someone throwing money at the cloud provider to run the attack on a host shared with your database, with no added benefits to them?
  - kevingadd 5y ago
    The implication of the post was that your own data analysis workloads could cause rowhammer flips unintentionally, I think.
    - PeterisP 5y ago
      That would be a wrong implication, your data analysis workloads (or any other "reasonable" reading of memory) are exceptionally unlikely to trigger these events unintentionally.
guerrilla 5y ago
> If you have a process running on your machine can it use this to get root? Read Keys? 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-Exploiting-The-DRAM-Rowhammer-Bug-To-Gain-Kernel-Privileges-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Seaborn-... 2. https://github.com/google/rowhammer-test/blob/master/rowhammer_test.cc https://github.com/google/rowhammer-test/blob/master/rowhamm...
- acomjean 5y ago
  Intersting. I can see taking the system down, especially on shared hardware. 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!
  - guerrilla 5y ago
    > 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. 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...
pomian 5y ago
Complex modeling, that runs for days, could have completly messed up results, especially since the old standard of using ECC, is not proof of infallibility. Often those results are in series, so early errors would compound, and it may very hard to determine if and why results are wrong.
TacticalCoder 5y ago
> If you have a process running on your machine can it use this to get root? Read Keys? 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.
cryptonector 5y ago
Cookie theft is the most important attack. Think about it. You could have a web page running who knows what scripts on your laptop while you're doing banking. Oops.

ARandumGuy 5y ago

That's my question as well. I'm not a security expert, but this doesn't seem all that concerning for anything other then the highest security applications. It seems to me that executing this attack not only requires running code on the target machine (which admittedly isn't that big of a hurdle), but requires basically complete knowledge of memory allocation at the time of the attack, something that is fairly opaque and ever changing on most hardware. Is there something I'm missing here? What are the realistic attacks that this vulnerability allows?

myself248 5y ago
There's no reason the code couldn't just blindly try every attack until it finds one that succeeds. If there's a malicious app that runs a lot (lookin' at you, random firefox tab that eats 99% of my CPU for minutes at a time and then goes idle again), it has all the time in the world.
pfortuny 5y ago
See my reply above: in-memory data analysis…
joebob42 5y ago
It might be hard to do a targeted attack. On the other hand, flipping random bits is likely to just start crashing stuff and / or producing incorrect results pretty reliably.
guerrilla 5y ago
See my reply, sibling to yours.
acuozzo 5y ago
> What are the realistic attacks that this vulnerability allows? https://github.com/IAIK/rowhammerjs https://github.com/IAIK/rowhammerjs

pfortuny 5y ago

This may be very bad for data analysts. Imagine trying to study a huge in-memory database and getting different values each time…

speedgoose 5y ago
Assuming you run your database in a public cloud, what's the likelihood of someone throwing money at the cloud provider to run the attack on a host shared with your database, with no added benefits to them?
- kevingadd 5y ago
  The implication of the post was that your own data analysis workloads could cause rowhammer flips unintentionally, I think.
  - PeterisP 5y ago
    That would be a wrong implication, your data analysis workloads (or any other "reasonable" reading of memory) are exceptionally unlikely to trigger these events unintentionally.

guerrilla 5y ago

> If you have a process running on your machine can it use this to get root? Read Keys? 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-Exploiting-The-DRAM-Rowhammer-Bug-To-Gain-Kernel-Privileges-wp.pdf https://www.blackhat.com/docs/us-15/materials/us-15-Seaborn-... 2. https://github.com/google/rowhammer-test/blob/master/rowhammer_test.cc https://github.com/google/rowhammer-test/blob/master/rowhamm...

acomjean 5y ago
Intersting. I can see taking the system down, especially on shared hardware. 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!
- guerrilla 5y ago
  > 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. 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...

pomian 5y ago

Complex modeling, that runs for days, could have completly messed up results, especially since the old standard of using ECC, is not proof of infallibility. Often those results are in series, so early errors would compound, and it may very hard to determine if and why results are wrong.

TacticalCoder 5y ago

> If you have a process running on your machine can it use this to get root? Read Keys? 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.

cryptonector 5y ago

Cookie theft is the most important attack. Think about it. You could have a web page running who knows what scripts on your laptop while you're doing banking. Oops.