Who else has seen this "Row-Hammer" stuff?
Here's the article: http://googleprojectzero.blogspot.com/2015/03/exploiting-dram-rowhammer-bug-to-gain.html
It's interesting to know that we've gotten so small in our architecture that inductance between PCB traces is an issue. But the first question that comes to mind is why are we pretending that this can be useful for anything other then maybe crashing a critical process? There is no way to predict how the adjacent row will be effected, or what RAM you'll be allocated in the first place, so you can't engineer the outcome. Or am I mistaken about that part? This is a genuine question, a lot of you know more about physics then I do.
It's interesting to know that we've gotten so small in our architecture that inductance between PCB traces is an issue. But the first question that comes to mind is why are we pretending that this can be useful for anything other then maybe crashing a critical process? There is no way to predict how the adjacent row will be effected, or what RAM you'll be allocated in the first place, so you can't engineer the outcome. Or am I mistaken about that part? This is a genuine question, a lot of you know more about physics then I do.
This is why it's taken a year to get from a theoretical vulnerability to a working exploit.
When a vulnerability is somewhat non-deterministic like this, it becomes a statistics game. Give yourself the best chance of success you can then repeatedly apply the exploit until you get the result you want.
The sorts of tricks you can use are things like knowing that if the least significant bit that gets flipped is at position x, then the difference between the original number and the modified number will be a multiple of 2^x. So, imagine you're trying to change some pointer to point to a piece of memory you control. The odds of you successfully picking the exact spot in memory is too small to be useful. If, however, you allocate a very large chunk of memory and repeat your payload throughout that memory at intervals of a low power of 2, say 32 bytes, then the likelihood of causing the pointer to jump to one of your target addresses becomes pretty good. Good enough that repeatedly trying the exploit until it succeeds is a viable strategy.
The page table exploit described in the Google paper for example, allocated about 3GB and filled it with target page table entries. This apparently takes on the order of a couple of seconds and does not require any special privileges to do.
When a vulnerability is somewhat non-deterministic like this, it becomes a statistics game. Give yourself the best chance of success you can then repeatedly apply the exploit until you get the result you want.
The sorts of tricks you can use are things like knowing that if the least significant bit that gets flipped is at position x, then the difference between the original number and the modified number will be a multiple of 2^x. So, imagine you're trying to change some pointer to point to a piece of memory you control. The odds of you successfully picking the exact spot in memory is too small to be useful. If, however, you allocate a very large chunk of memory and repeat your payload throughout that memory at intervals of a low power of 2, say 32 bytes, then the likelihood of causing the pointer to jump to one of your target addresses becomes pretty good. Good enough that repeatedly trying the exploit until it succeeds is a viable strategy.
The page table exploit described in the Google paper for example, allocated about 3GB and filled it with target page table entries. This apparently takes on the order of a couple of seconds and does not require any special privileges to do.
Maybe it's the name that is misleading me? It's a bit-flip, not a byte-flip. So supposedly it's only changing one bit at a time. Now this might be workable if you can be assured that you are changing one of the MSB's without affecting either value adjacent to it, but I don't see how you could have the amount of control you need to assure that. I've looked over their code and what I see are a bunch of magic numbers that you would need to have a debugger to determine in the first place. Otherwise you shouldn't have the access you would need to determine those values to begin with.
Let's assume for a second that you could manage this much control over a jump instruction. You still don't know where everything else is, so now what? You cause a application A to jump into application B's memory space, that's a Seg Fault. Congratulations on your immediate termination.
There is also no mention in the article of DEP which makes me suspicious. Don't get me wrong, it's a really cool quirk to point out. But I can't imagine it having a realistic purpose in a tool chain.
Let's assume for a second that you could manage this much control over a jump instruction. You still don't know where everything else is, so now what? You cause a application A to jump into application B's memory space, that's a Seg Fault. Congratulations on your immediate termination.
There is also no mention in the article of DEP which makes me suspicious. Don't get me wrong, it's a really cool quirk to point out. But I can't imagine it having a realistic purpose in a tool chain.
Topic archived. No new replies allowed.