5 ms·

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 i

by 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.

by 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.