21

Since this new class of attacks involves measuring precise time intervals, as a partial, short-term, mitigation we are disabling or reducing the precision of several time sources in Firefox. The precision of performance.now() has been reduced from 5μs to 20μs, and the SharedArrayBuffer feature has been disabled because it can be used to construct a high-resolution timer.

Mozilla Foundation Security Advisory 2018-01

How can SharedArrayBuffer be used to construct a high-resolution timer? Isn't it just a buffer with special rules that allow it to be directly passed to another context rather than cloning it?

Community
  • 1
curiousdannii
  • 350
  • 3
  • 12
  • one thread can go balls-to-the-wall incrementing a counter stored in such an array while another thread, relatively idle, can read that counter at any time without introducing it's own timing determination overhead. – dandavis Jan 08 '18 at 05:38
  • 2
    https://gruss.cc/files/fantastictimers.pdf – Bergi Jan 11 '18 at 13:32

1 Answers1

19

SharedArrayBuffer allows two threads to share state, so one can operate as a "clock" (incrementing the timing signal) and the other can read the "clock". Additionally, the availability of the Atomics object allows performing operations on the SharedArrayBuffer in a fashion that makes incrementing efficient and can be seen by the reading thread without the risk of a race condition.

This timer is, admittedly, only in units of "how fast the other thread increments" and not "seconds", but for timing attacks, the interesting data for an attacker is relative timing. Knowing that a given cache line (in the case of Spectre) loads faster than others reveals that it has been precached by the CPU. The same holds true for timing attacks on things like password comparisons (correct characters take some proportion longer than incorrect characters).

It would be possible to calibrate a fast timing loop against a known clock reference (i.e., from performance.now()) to get an average time per increment, but there would still be some small jitter.

David
  • 15,814
  • 3
  • 48
  • 73
  • Such a clock would have to be calibrated against an actual system clock, right? Or maybe since Spectre is just about testing relative cache access times, it doesn't even need to be calibrated? – curiousdannii Jan 08 '18 at 05:59
  • 5
    @curiousdannii For most timing attacks (including Spectre), *relative* timing is what is desirable. Finding cache lines that load faster (because they're in the CPU cache) is all that is necessary. Knowing a precise time in some fractions of seconds is not needed. – David Jan 08 '18 at 06:01
  • Absolute timing also suffers from differing processor frequency, IPC, memory setup and possibly environment. – kristjan Jan 08 '20 at 11:02