6 ms·

> we are disabling or reducing the precision of several time sources I am really happy to see this happening at long last. One can argue that almost every x86

by rphlx 9y ago

> we are disabling or reducing the precision of several time sources I am really happy to see this happening at long last. One can argue that almost every x86 SW side channel attack (Spectre and many prior ones that, for instance, leak parts of cryptographic keys from variable-time SW implementations) are being aided by userspace processes having access to high-frequency/high-res counters for which, in almost every case, they have no legitimate need. Perhaps future silicon should block direct access to the TSC & friends, except for processes that have a privileged flag set (hardly a new idea; IIRC some IBM PowerPC chips from the late 90s support that). OS-level timing calls such as gettimeofday() could be degraded to a few microseconds resolution by default - poor enough to obscure delays caused by the state of various HW caches, branch predictors, etc. Ultimately there is little reason to give every website js program access to a nanosecond-level counter by default, and many defense-in-depth reasons for not doing that. So kudos to the firefox team here and hopefully chrom[e|ium] quickly copies this.

quotemstr 9y ago
Timer coarsening is a bad idea. Turns out [1], a simple timer thread is a good enough poor man's cycle counter. What are you going to do: ban variables? Even if you could coarsen timers, adding random noise just makes attacks take longer. It doesn't make them impossible; attackers can just collect more measurements. You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. [1] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf https://www.usenix.org/system/files/conference/usenixsecurit...
- deleted 9y ago
  [deleted]
- rphlx 9y ago
  > adding random noise just makes attacks take longer No. It's true that with a low-res clock source in some cases an attacker can still get the precise measurement they're after by repeating an operation 1000x+ more times. In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc. Anyway, even if a lower-res clock source helps only 10% of the time, on defense you should always prefer to make an attack complicated, slow, partially-reliable rather than trivial, fast, highly-reliable. Developers who need a high-res clock source for profiling, etc, should of course still be able to enable one selectively. > You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. You can and should do both, to gain some defense-in-depth against future attacks.
  - deleted 9y ago
    [deleted]
  - contrarian_ 9y ago
    > In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc. Wrong, those signals will average out over a long enough data collection time.
    - foota 9y ago
      I'm not sure that's true in this case, if your timer doesn't have the resolution to ever detect a cache hit, how can you measure impact?
      - deleted 9y ago
        [deleted]
      - blattimwind 9y ago
        It's one of those things that feel utterly counter-intuitive. But if you have a signal overlaid with random noise [1], and you know what your signal's looking like and when it's happening, you can correlate. For example, a small delay that occurs at certain known points (or not), will introduce a bias into a timer measuring it, no matter how noisy or coarsely quantized that timer is. Similar techniques have been used in other fields for decades to pull useful signals from far below the noise floor (e.g. a lock in amplifier can go dozens of dB below the noise floor, because it, essentially, correlates frequency and phase and thereby eliminates all but a tiny sliver of noise. E.g. GPS signals are typically 20 dB below the noise floor. [1] It doesn't have to be random. —— So these mitigations just make the attacks harder, hopefully hard enough that they become not feasible to be exploited widely.
        FreeHugs 9y ago
        Then why can't we make sharp high resolution photos of distant planets? Shouldn't we be able to average out all the noise for every pixel if we just collect light long enough?
the8472 9y ago
JS code or containerized code running on shared hardware are one thing. But crippling all userspace applications seems like going too far. Especially considering this is just papering over the problem instead of fixing it. Also note that if you reduce precision you might still be able to tease out the data simply by gathering more samples. An exploit that gets you 1000bytes per minute might take an hour instead, but that could be enough to find cryptographic keys.
- r00fus 9y ago
  Can you tell me which apps would suffer because of timer coarsening?
  - macawfish 9y ago
    Simulations, real time audio applications (filters, effects, etc.), real time anything for that matter, performance profilers... just of the top of my head.
    - r00fus 9y ago
      at a granularity of 20µs?
      - macawfish 9y ago
        Well, since 1/20µs = 50 kHz, it strikes me that this threshold was probably chosen with audio in mind. I agree that for a lot of cases, it's plenty. But if you're trying to account for phase differences in multiple data sources, this puts a major blindfold on. Let's think about it in terms of lower frequencies. Imagine that you're sampling from a pool of events that occur roughly 100 times/hour. Let's say you want to sample 2 event per hour. Well you might say "since you're only sampling at a rate of 2/hr, why would you need any better granularity than 30 minutes?" Here's the catch: you need to get the event that's closest to the 15 minute mark of each hour and the one that's closest to the 30 minute mark; you will then put those two together using your special formula. Imagine that all your events came into a mailbox on an half-hourly basis. Imagine a stack of ~100 envelopes, each labeled "8 - 8:30 A.M." or "8:30 - 9 A.M.". You're tasked tasked with the job of trying to pick the two closest to 8:15 A.M. and 8:30 A.M. Good luck! It's gonna be hard, if not impossible, to do this consistently with any accuracy. (Even if you had 15 minute granularity, you'd still have to pick from each one from either 25 or 50 envelopes, depending on where the windows fall relative to the 15 minute marks.) Now, to make matters even more complicated, imagine a situation where you're integrating each hour's result with the previous hours' result, e.g. taking a rolling sum or product, or computing some kind of feedback/delay/reverb filter. In cases like that, you're done for. Full disclosure, I'm coming at this from the perspective of an experimental digital artist who some day would like to do interesting creative things with high frequency sources, like the sounds of bugs, dolphins, and higher frequency ambient sounds. I'm also interested in building applications that crowd-source and integrate audio from multiple smart-phones in a room. The web seemed like a perfect platform for this.
saurik 9y ago
It is still possible to exploit a timing attack with a low resolution timer; it simply takes more samples. Meanwhile, people have managed to perform timing attacks (such as against OpenSSL) across a network (see the link below where I link to the seminal paper, "Remote Timkng Attacks are Practical"), as while the latency is large and variable it can still be trivially characterized. So, unless you are willing to apply a truly unpredictable delay function (some kind of Turing-complete noise which sometimes might block for arbitrary amounts of time) or, alternatively, a delay long enough to reauire the user to sit on the web page for "too long" (maybe weeks is the right calibration? I often find sketchy tabs that have been open for days) to essentially everything--and, in particular, all JS-initiated network requests--then you are likely just engaging in security theater by removing useful functionality from an API because it makes you feel more secure. https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf
- rphlx 9y ago
  There are other side channels where an attacker cannot cause the desired operation to be repeated thousands or millions of times back-to-back.. If Alice performs an operation only once, and it leaks sensitive data through a timing variation of 100-200ns, Mallory is in great shape with a 1ns clock source and in pretty awful shape with a 10us one.
jnwatson 9y ago
The problem with coarsening timers is that many things can be used as one. Performance registers, received packet timing are just the obvious ones. This problem has been studied a lot. The venerable TCSEC Rainbow Series dedicates an entire volume to covert channels (the light pink one iirc). It is a statistical problem. Even if you reduce the timing precision or randomize it and effectively raise the noise floor, it just takes a little bit longer for the attacker to get his data. A good analogy would be Differential Power Analysis (DPA). Measurements are collected over a period of time to enhance the signal.
fpoling 9y ago
Typically timing attacks do not need absolute time. So for high precision timer one can just use a counter loop in a separated thread. This is even possible in JavaScript with web workers.
- rphlx 9y ago
  That's a fair point, but let me note that it is still less desirable (to an attacker) than the TSC in at least one case: when system load is high enough that there are other non-attacker-controlled threads running on the same core. When the counter thread's not running, the counter thread's not counting, and this loss of accuracy could at least in theory complicate an attack.
  - xxs 9y ago
    >>this loss of accuracy could at least in theory complicate an attack. It just takes more samples and in the end it solves nothing. >>non-attacker-controlled threads running on the same core. Again it might take more samples. However, worse: the system is like unresponsive at the time. Also the timeslices are long enough to carry the task, unless there are way, way too many and unpredictable context switches (which would be bad for performance). ---- Back in the days of old there were no built-in timers and people used to count cpu cycles to accommodate for external io.
nbsd4lyfe 9y ago
You can block access to rdtsc right now by setting CR4.TSD
- Retr0spectrum 9y ago
  Seccomp does this in most kernel versions I believe: http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html http://blog.cr0.org/2009/05/time-stamp-counter-disabling-odd...
semi-extrinsic 9y ago
More interesting IMO is this part of the announcement: > In the longer term, we have started experimenting with techniques to remove the information leak closer to the source, instead of just hiding the leak by disabling timers. This project requires time to understand, implement and test, but might allow us to consider reenabling SharedArrayBuffer and the other high-resolution timers as these features provide important capabilities to the Web platform.
sevenfive 9y ago
The authors note in the Spectre paper that Chrome already does this, and they can get around it with a timer thread.
- rphlx 9y ago
  Did they note any change in attack duration or success rate with that vs a high-res HW counter?
frik 9y ago
We need "NoScript" addon in current Firefox!!! No other addon (even umatrix) offers what NoScript does, yet NoScript doesn't work anymore :( And better entirely disable WebAsm (in config) to avoid another attack vector.

by rphlx 9y ago

quotemstr 9y ago

Timer coarsening is a bad idea. Turns out [1], a simple timer thread is a good enough poor man's cycle counter. What are you going to do: ban variables? Even if you could coarsen timers, adding random noise just makes attacks take longer. It doesn't make them impossible; attackers can just collect more measurements. You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. [1] https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf https://www.usenix.org/system/files/conference/usenixsecurit...

deleted 9y ago
[deleted]
rphlx 9y ago
> adding random noise just makes attacks take longer No. It's true that with a low-res clock source in some cases an attacker can still get the precise measurement they're after by repeating an operation 1000x+ more times. In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc. Anyway, even if a lower-res clock source helps only 10% of the time, on defense you should always prefer to make an attack complicated, slow, partially-reliable rather than trivial, fast, highly-reliable. Developers who need a high-res clock source for profiling, etc, should of course still be able to enable one selectively. > You need to address the specific vulnerabilities, not shoot the clock_gettime messenger. You can and should do both, to gain some defense-in-depth against future attacks.
- deleted 9y ago
  [deleted]
- contrarian_ 9y ago
  > In some cases though that is not possible, because at that timescale the signal they're after is degraded by noise that they cannot predict or control: operating system interrupts, memory traffic from other threads, etc. Wrong, those signals will average out over a long enough data collection time.
  - foota 9y ago
    I'm not sure that's true in this case, if your timer doesn't have the resolution to ever detect a cache hit, how can you measure impact?
    - deleted 9y ago
      [deleted]
    - blattimwind 9y ago
      It's one of those things that feel utterly counter-intuitive. But if you have a signal overlaid with random noise [1], and you know what your signal's looking like and when it's happening, you can correlate. For example, a small delay that occurs at certain known points (or not), will introduce a bias into a timer measuring it, no matter how noisy or coarsely quantized that timer is. Similar techniques have been used in other fields for decades to pull useful signals from far below the noise floor (e.g. a lock in amplifier can go dozens of dB below the noise floor, because it, essentially, correlates frequency and phase and thereby eliminates all but a tiny sliver of noise. E.g. GPS signals are typically 20 dB below the noise floor. [1] It doesn't have to be random. —— So these mitigations just make the attacks harder, hopefully hard enough that they become not feasible to be exploited widely.
      - FreeHugs 9y ago
        Then why can't we make sharp high resolution photos of distant planets? Shouldn't we be able to average out all the noise for every pixel if we just collect light long enough?

the8472 9y ago

JS code or containerized code running on shared hardware are one thing. But crippling all userspace applications seems like going too far. Especially considering this is just papering over the problem instead of fixing it. Also note that if you reduce precision you might still be able to tease out the data simply by gathering more samples. An exploit that gets you 1000bytes per minute might take an hour instead, but that could be enough to find cryptographic keys.

r00fus 9y ago
Can you tell me which apps would suffer because of timer coarsening?
- macawfish 9y ago
  Simulations, real time audio applications (filters, effects, etc.), real time anything for that matter, performance profilers... just of the top of my head.
  - r00fus 9y ago
    at a granularity of 20µs?
    - macawfish 9y ago
      Well, since 1/20µs = 50 kHz, it strikes me that this threshold was probably chosen with audio in mind. I agree that for a lot of cases, it's plenty. But if you're trying to account for phase differences in multiple data sources, this puts a major blindfold on. Let's think about it in terms of lower frequencies. Imagine that you're sampling from a pool of events that occur roughly 100 times/hour. Let's say you want to sample 2 event per hour. Well you might say "since you're only sampling at a rate of 2/hr, why would you need any better granularity than 30 minutes?" Here's the catch: you need to get the event that's closest to the 15 minute mark of each hour and the one that's closest to the 30 minute mark; you will then put those two together using your special formula. Imagine that all your events came into a mailbox on an half-hourly basis. Imagine a stack of ~100 envelopes, each labeled "8 - 8:30 A.M." or "8:30 - 9 A.M.". You're tasked tasked with the job of trying to pick the two closest to 8:15 A.M. and 8:30 A.M. Good luck! It's gonna be hard, if not impossible, to do this consistently with any accuracy. (Even if you had 15 minute granularity, you'd still have to pick from each one from either 25 or 50 envelopes, depending on where the windows fall relative to the 15 minute marks.) Now, to make matters even more complicated, imagine a situation where you're integrating each hour's result with the previous hours' result, e.g. taking a rolling sum or product, or computing some kind of feedback/delay/reverb filter. In cases like that, you're done for. Full disclosure, I'm coming at this from the perspective of an experimental digital artist who some day would like to do interesting creative things with high frequency sources, like the sounds of bugs, dolphins, and higher frequency ambient sounds. I'm also interested in building applications that crowd-source and integrate audio from multiple smart-phones in a room. The web seemed like a perfect platform for this.

saurik 9y ago

It is still possible to exploit a timing attack with a low resolution timer; it simply takes more samples. Meanwhile, people have managed to perform timing attacks (such as against OpenSSL) across a network (see the link below where I link to the seminal paper, "Remote Timkng Attacks are Practical"), as while the latency is large and variable it can still be trivially characterized. So, unless you are willing to apply a truly unpredictable delay function (some kind of Turing-complete noise which sometimes might block for arbitrary amounts of time) or, alternatively, a delay long enough to reauire the user to sit on the web page for "too long" (maybe weeks is the right calibration? I often find sketchy tabs that have been open for days) to essentially everything--and, in particular, all JS-initiated network requests--then you are likely just engaging in security theater by removing useful functionality from an API because it makes you feel more secure. https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf https://crypto.stanford.edu/~dabo/papers/ssl-timing.pdf

rphlx 9y ago
There are other side channels where an attacker cannot cause the desired operation to be repeated thousands or millions of times back-to-back.. If Alice performs an operation only once, and it leaks sensitive data through a timing variation of 100-200ns, Mallory is in great shape with a 1ns clock source and in pretty awful shape with a 10us one.

jnwatson 9y ago

The problem with coarsening timers is that many things can be used as one. Performance registers, received packet timing are just the obvious ones. This problem has been studied a lot. The venerable TCSEC Rainbow Series dedicates an entire volume to covert channels (the light pink one iirc). It is a statistical problem. Even if you reduce the timing precision or randomize it and effectively raise the noise floor, it just takes a little bit longer for the attacker to get his data. A good analogy would be Differential Power Analysis (DPA). Measurements are collected over a period of time to enhance the signal.

fpoling 9y ago

Typically timing attacks do not need absolute time. So for high precision timer one can just use a counter loop in a separated thread. This is even possible in JavaScript with web workers.

rphlx 9y ago
That's a fair point, but let me note that it is still less desirable (to an attacker) than the TSC in at least one case: when system load is high enough that there are other non-attacker-controlled threads running on the same core. When the counter thread's not running, the counter thread's not counting, and this loss of accuracy could at least in theory complicate an attack.
- xxs 9y ago
  >>this loss of accuracy could at least in theory complicate an attack. It just takes more samples and in the end it solves nothing. >>non-attacker-controlled threads running on the same core. Again it might take more samples. However, worse: the system is like unresponsive at the time. Also the timeslices are long enough to carry the task, unless there are way, way too many and unpredictable context switches (which would be bad for performance). ---- Back in the days of old there were no built-in timers and people used to count cpu cycles to accommodate for external io.

nbsd4lyfe 9y ago

You can block access to rdtsc right now by setting CR4.TSD

Retr0spectrum 9y ago
Seccomp does this in most kernel versions I believe: http://blog.cr0.org/2009/05/time-stamp-counter-disabling-oddities.html http://blog.cr0.org/2009/05/time-stamp-counter-disabling-odd...

semi-extrinsic 9y ago

More interesting IMO is this part of the announcement: > In the longer term, we have started experimenting with techniques to remove the information leak closer to the source, instead of just hiding the leak by disabling timers. This project requires time to understand, implement and test, but might allow us to consider reenabling SharedArrayBuffer and the other high-resolution timers as these features provide important capabilities to the Web platform.

sevenfive 9y ago

The authors note in the Spectre paper that Chrome already does this, and they can get around it with a timer thread.

rphlx 9y ago
Did they note any change in attack duration or success rate with that vs a high-res HW counter?

frik 9y ago

We need "NoScript" addon in current Firefox!!! No other addon (even umatrix) offers what NoScript does, yet NoScript doesn't work anymore :( And better entirely disable WebAsm (in config) to avoid another attack vector.