4 ms·

Non-engineer here, this bit is key right: > However, suppose we flush our cache before executing the code, and arrange a, b, c, and d so that v is zero. Now,

Non-engineer here, this bit is key right: > However, suppose we flush our cache before executing the code, and arrange a, b, c, and d so that v is zero. Now, the speculative load in the third cycle: > v, y_ = u+d, user_mem[x_] > will read from either address 0x000 or address 0x100 depending on the eighth bit of the result of the illegal read. Because v is zero, the results of the speculative instructions will be discarded, and execution will continue. If we time a subsequent access to one of those addresses, we can determine which address is in the cache. Congratulations: you’ve just read a single bit from the kernel’s address space! To my understanding it is that saying that by... 1) ...flushing the cache so you have a 'clean' state, you can get... 2) ...the speculative execution to 'pull in' to cache the address user_mem[x_] but... 3) ...the particular address that's pulled into cache, 0x000 or 0x100, is determined by whether... 4) ...the illegal read of kern_mem[address] 8th bit was a 1 or 0... 5) ...which you can then subsequently determine the value of by... 6) ...timing how long it takes to access that user_mem[x] address once again and... 7) ...thereby leaking the value of kern_mem[address]... So you still have to perform some logic on the result of the speed of the access to the secondary address read right? If read of 0x000 is slow you know kern_mem[address] was a 1 and if fast kern_mem[address] a 0, and if 0x100 is slow you know kern_mem[address] was a 0 and if fast that kern_mem[address] was a 1? Is that correct? If it is it seems that timing is the key right, and actually the clever leap of creativity in completing the exploit, at least to my untrained mind. Please do correct anything I've got wrong, I'm not an engineer/developer!

pilom 9y ago
You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.
- O_H_E 9y ago
  Does that mean -another- slight performance drop ???
  - mjevans 9y ago
    It means the only secure system is one where the performance of any given instruction is constant in all cases for that instruction.
    - tempestn 9y ago
      A system like that would certainly be secure against these types of attacks, but I don't believe there is evidence that that is the only secure system. It certainly opens up many of these sorts of problems, but that just means it is difficult to secure, not impossible.
  - tialaramex 9y ago
    Not in general. Consider an Olympic 100 metre sprinter. Today we time this event very accurately, I think it's to one hundredth of a second, using sophisticated technology. But even if the judges used a much less accurate mechanical stopwatch, Usain Bolt wouldn't actually be slower, we'd just be less confident of how ridiculously fast he is. In some special cases, timing things very accurately might be essential to a use of Javascript, but I can't think of any examples off the top of my head.
    - make3 9y ago
      gotta get that sweet rollover effect right to the 24th decimal baby
- CamperBob2 9y ago
  You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not. What does that do, besides turn the exfiltration problem from an immediate one into a statistical one?
  - eximius 9y ago
    IF it can be turned into a statistical problem, it may become an infeasible attack. You'd have to run the whole attack (not just the last reading bit since that would bring it into the cache after the first read) many times to be able to ascertain the difference. Even then, the difference might be less than the noise from other processes on the system (I think 80 cycles was used in the PoC?). Maybe there will end up being a new Jumping Around Kernal Address Space System (JAKASS - a cousin of Linux's FUKWIT patch) that periodically resets kernel ASRL to make it fully impossible.
    - floatboth 9y ago
      This Mozilla post https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... mentions that "other timing sources and time-fuzzing techniques are being worked on". The paper they linked to references this one: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_kohlbrenner.pdf https://www.usenix.org/system/files/conference/usenixsecurit... I think this is what all sandboxes have to do: set the TSC disable flag, restrict system timer precision (make it configurable per sandbox: web servers generally don't need more than 1ms precision), make system timer report fuzzy (randomized) time. Heck, why not also make the CPU run at randomized frequency to mess with busy loop timers.

pilom 9y ago

You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not.

O_H_E 9y ago
Does that mean -another- slight performance drop ???
- mjevans 9y ago
  It means the only secure system is one where the performance of any given instruction is constant in all cases for that instruction.
  - tempestn 9y ago
    A system like that would certainly be secure against these types of attacks, but I don't believe there is evidence that that is the only secure system. It certainly opens up many of these sorts of problems, but that just means it is difficult to secure, not impossible.
- tialaramex 9y ago
  Not in general. Consider an Olympic 100 metre sprinter. Today we time this event very accurately, I think it's to one hundredth of a second, using sophisticated technology. But even if the judges used a much less accurate mechanical stopwatch, Usain Bolt wouldn't actually be slower, we'd just be less confident of how ridiculously fast he is. In some special cases, timing things very accurately might be essential to a use of Javascript, but I can't think of any examples off the top of my head.
  - make3 9y ago
    gotta get that sweet rollover effect right to the 24th decimal baby
CamperBob2 9y ago
You're exactly correct. This is why the browsers decreased timing resolution in javascript so that you couldn't time memory accesses accurately enough to tell if the address was cached or not. What does that do, besides turn the exfiltration problem from an immediate one into a statistical one?
- eximius 9y ago
  IF it can be turned into a statistical problem, it may become an infeasible attack. You'd have to run the whole attack (not just the last reading bit since that would bring it into the cache after the first read) many times to be able to ascertain the difference. Even then, the difference might be less than the noise from other processes on the system (I think 80 cycles was used in the PoC?). Maybe there will end up being a new Jumping Around Kernal Address Space System (JAKASS - a cousin of Linux's FUKWIT patch) that periodically resets kernel ASRL to make it fully impossible.
  - floatboth 9y ago
    This Mozilla post https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/ https://blog.mozilla.org/security/2018/01/03/mitigations-lan... mentions that "other timing sources and time-fuzzing techniques are being worked on". The paper they linked to references this one: https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_kohlbrenner.pdf https://www.usenix.org/system/files/conference/usenixsecurit... I think this is what all sandboxes have to do: set the TSC disable flag, restrict system timer precision (make it configurable per sandbox: web servers generally don't need more than 1ms precision), make system timer report fuzzy (randomized) time. Heck, why not also make the CPU run at randomized frequency to mess with busy loop timers.