4 ms·

> the attacker does in fact need to be able to get the targeted system to run something somehow >Unfortunately that includes Javascript, and now that affects v

> the attacker does in fact need to be able to get the targeted system to run something somehow >Unfortunately that includes Javascript, and now that affects virtually everybody. Debatable -- not because of the goofballs who insist on never running javascript, but because it doesn't have the necessary clock precision available.

_0w8t 4y ago
When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be disabled again as it may allow to monitor frequency changes.
- jabart 4y ago
  My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the returned time to 1 millisecond increments."
  - contravariant 4y ago
    Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?
    - SOLAR_FIELDS 4y ago
      I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?
      - arpafaucon 4y ago
        If you round up and down with the same probability, it will get canceled on the long run. I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a < b => round(a) < round(b) So I'd say "not worth it"
        rswail 4y ago
        Minor correction: iff |a| < |b| then round(|a|) < = round(|b|)
    - vajrabum 4y ago
      Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?
      - danielheath 4y ago
        Example: You need to know how whether an operation takes 30 or 31 milliseconds, but your timer is rounded to the nearest 100ms, so you just get 0 or 100. If you repeat the operation 100 times and time how long that takes, you should either get 3000 or 3100 milliseconds.
        usrusr 4y ago
        ..and a dramatically increased likelihood of something unrelated going on in the system ruining your results. It's easy to dismiss mitigations like this as "not a solution", but at least those that add uncertainty to sidechannel attacks seem to complement each other quite nicely. Uncertainties don't add, they multiply.
    - thristian 4y ago
      Same as any security: making an attack more expensive to mount means people are less likely to try it. If high-resolution timers allow you to mount an attack in the three minutes the target takes to read a listicle page, then rounded timers require the target to keep the page open in the foreground for 3000 minutes, or 50 hours. That's much more difficult to do.
  - josefx 4y ago
    If I remember correctly they also had to disable shared array buffers because a thread just incrementing a shared value can be used as timer.
- icedchai 4y ago
  There were proof of concepts. Were there ever any actual real world attacks?
  - jnordwick 4y ago
    never. nothing ever recovered in a root kit. nothing seen for sale. even the original POCs were horrible biased and didn't work. simple moving the targeted buffer around in memory would have make it virtually impossible to exfiltrate it.
smaudet 4y ago
I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to. Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web? 99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up malicious...
- joveian 4y ago
  I do this with uBlock Origin. It is easy and I'd say less impactful than blocking third party domain (de-CNAMEd) CDNs by default (that I also do). Some sites just don't show anything without javascript, though, so it works best if you are often willing to just ignore those sites (not common but not all that uncommon either).

_0w8t 4y ago

When Spectre came it turned out that it was very straightforward to implement the relevant attacks in JS. A script can use workers with shared memory access to monitor execution and get a timer with less than 100ns resolution. As the result the shared memory were disabled. Later under the presumption that relevant issues were mitigated, the shared memory was re-enabled again. So I wonder if the shared memory will be disabled again as it may allow to monitor frequency changes.

jabart 4y ago
My understanding was that the timer precision was limited and that was never re-enabled. From MDN. "It's important to keep in mind that to mitigate potential security threats such as Spectre, browsers typically round the returned value by some amount in order to be less predictable. This inherently introduces a degree of inaccuracy by limiting the resolution or precision of the timer. For example, Firefox rounds the returned time to 1 millisecond increments."
- contravariant 4y ago
  Could anyone explain how rounding the timing protects against just running the thing you want timed 1000 times to get microsecond precision?
  - SOLAR_FIELDS 4y ago
    I know next to nothing about the internals of how the rounding code works, but couldn't randomly choosing to round up or down mitigate this somewhat?
    - arpafaucon 4y ago
      If you round up and down with the same probability, it will get canceled on the long run. I suppose this does mitigate the risk a little, but risks breaking other things. For example, you don't have the simple logic sequence: a < b => round(a) < round(b) So I'd say "not worth it"
      - rswail 4y ago
        Minor correction: iff |a| < |b| then round(|a|) < = round(|b|)
  - vajrabum 4y ago
    Isn't rounding pretty much the same thing as throwing away some precision in this case? So if I drop some (enough) bits and add .5 then no amount of averaging is going to recover the lost precision. Or maybe I misunderstand?
    - danielheath 4y ago
      Example: You need to know how whether an operation takes 30 or 31 milliseconds, but your timer is rounded to the nearest 100ms, so you just get 0 or 100. If you repeat the operation 100 times and time how long that takes, you should either get 3000 or 3100 milliseconds.
      - usrusr 4y ago
        ..and a dramatically increased likelihood of something unrelated going on in the system ruining your results. It's easy to dismiss mitigations like this as "not a solution", but at least those that add uncertainty to sidechannel attacks seem to complement each other quite nicely. Uncertainties don't add, they multiply.
  - thristian 4y ago
    Same as any security: making an attack more expensive to mount means people are less likely to try it. If high-resolution timers allow you to mount an attack in the three minutes the target takes to read a listicle page, then rounded timers require the target to keep the page open in the foreground for 3000 minutes, or 50 hours. That's much more difficult to do.
- josefx 4y ago
  If I remember correctly they also had to disable shared array buffers because a thread just incrementing a shared value can be used as timer.
icedchai 4y ago
There were proof of concepts. Were there ever any actual real world attacks?
- jnordwick 4y ago
  never. nothing ever recovered in a root kit. nothing seen for sale. even the original POCs were horrible biased and didn't work. simple moving the targeted buffer around in memory would have make it virtually impossible to exfiltrate it.

smaudet 4y ago

I don't have a problem running JS but it is getting to the point where, if you can't prove you are JS worth running perhaps the browser should refuse to. Why have we gone from 'oh only run programs you trust not anything from the web' to 'oh just run every bit of bloatware out there any time you move around the web? 99% of JS should not exist, 0.9 % of it does anything useful and the other .1% is straight up malicious...

joveian 4y ago
I do this with uBlock Origin. It is easy and I'd say less impactful than blocking third party domain (de-CNAMEd) CDNs by default (that I also do). Some sites just don't show anything without javascript, though, so it works best if you are often willing to just ignore those sites (not common but not all that uncommon either).