
Mitigations landing for new class of timing attack - Nrbelex
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
======
rphlx
> 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
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/usenixsecurit...](https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_lipp.pdf)

~~~
rphlx
> 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.

~~~
contrarian_
> 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
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?

~~~
blattimwind
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
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?

~~~
contrarian_
No, because there's correlated noise: all the stuff in between us and the
planet.

~~~
FreeHugs
What type of stuff is between us and the planet and stays on the same pixel
all the time? I would assume everything in the universe moves all the time. We
move. The other planet moves. How can something block the same pixel of our
view of the planet all the time?

~~~
sp332
I don't think other planets usually move enough to cross one pixel. They've
mostly been detected by changes in brightness of their host star.
[https://en.wikipedia.org/wiki/Methods_of_detecting_exoplanet...](https://en.wikipedia.org/wiki/Methods_of_detecting_exoplanets#Established_detection_methods)

------
Sephr
I warned about high accuracy SharedArrayBuffer-based timers on Hacker News[1]
when Firefox and Chrome were adding SharedArrayBuffers.

Glad to see people finally waking up to the fact that high accuracy timers are
security vulnerabilities on most synchronous systems.

1\.
[https://news.ycombinator.com/item?id=14057091](https://news.ycombinator.com/item?id=14057091)

~~~
fulafel
Why is SAB different from other improvised clocks? Are other operations too
slow?

~~~
fpoling
The other operations, like posting messages, have much higher latency noise.
SAB allows to observe counter changes effectively within few CPU cycles with
stable latency.

------
anon1385
Mozilla previously reduced the precision of performance.now() to 5µs. This was
trivially defeated by just running performance.now() in a tight loop, as
described here:
[http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pd...](http://www.cs.vu.nl//~herbertb/download/papers/anc_ndss17.pdf)
see the technique in section IV called time to tick (TTT):

>The idea behind the TTT measurement, as shown in Figure 4.4, is quite simple.
Instead of measuring how long a memory reference takes with the timer (which
is no longer possible), we count how long it takes for the timer to tick after
the memory reference takes place. More precisely, we first wait for
performance.now() to tick, we then execute the memory reference, and then
count by executing performance.now() in a loop until it ticks. If memory
reference is a fast cache access, we have time to count more until the next
tick in comparison to a memory reference that needs to be satisfied through
main memory.

>TTT performs well in situations where performance.now() does not have jitter
and ticks at regular intervals such as in Firefox. We, however, believe that
TTT can also be used in performance.now() with jitter as long as it does not
drift, but it will require a higher number of measurements to combat jitter.

So, what stops this method from working, even with 20µs resolution
performance.now()?

~~~
tormeh
Maybe the clock can be made to drift? You can make the clock a random walk
with the restriction that it never decreases, and doesn't deviate more than
20us? That is, each tick of the clock actually just adds a non-negative
interval to the clock. Since the deviation from real time at _tick_ depends on
the deviation at _tick-1_ it would require more time to get good accuracy by
averaging measurements.

~~~
contrarian_
Run it for long enough and you can average out the random drift.

The issue cannot be fixed without disabling speculation entirely on current
hardware.

------
kbwt
> The resolution of performance.now() will be reduced to 20µs.

That will reduce the data rate of this particular covert channel, not prevent
the attack altogether. Even adding random noise would not rule out the attack.

~~~
discoursism
Presumably they are aware of this. If they reduce the data rate enough, the
attack becomes less useful in practice. Presumably their engagements with
security researchers and other browser vendors, along with internal
experimentation, led them to believe that this resolution decrease offered
significant mitigation.

------
usernam
Reducing the resolution coming from system timing sources is not going to stop
attacks which have potentially infinite execution timelines.

Limiting JS execution resources, and in particular CPU cycles, will actually
stop instead a whole swath of timing and resource-dependent attacks.

Please put your thought and chime into this thread:

[https://bugzilla.mozilla.org/show_bug.cgi?id=1414675](https://bugzilla.mozilla.org/show_bug.cgi?id=1414675)

Allowing infinite resources for remote programs is something we don't even do
for _local_ programs. Giving a ceiling to the JS runtime is a _sound_
reasoning.

Please comment on the bug tracker!

~~~
usernam
Commenting on the upstream bug tracker would do so much more than lazily
clicking upvote.

------
Azeralthefallen
So a quick question. What is the alternative to SharedArrayBuffer? One of the
web applications i work on use it a fair amount. Is our app now just going to
break?

~~~
oneweekwonder
The feature was previously hidden behind a about:config option[0]. Not a ff
user but might check if it is back and for now let your users now?

Is chrome or edge affected?

Should the SharedArrayBuffer mdn page be updated; or maybe moz://a will fix it
quickly enough to allow it on by default again.

By the looks of it, this will affect a lot of webgl code.

[0]: [https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Refe...](https://developer.mozilla.org/en-
US/docs/Web/JavaScript/Reference/Global_Objects/SharedArrayBuffer#compatNote_2)

~~~
tedivm
Chrome will be taking the same steps-

> In line with other browsers, Chrome 64 will disable SharedArrayBuffer and
> modify the behaviour of other APIs such as performance.now, to help reduce
> the efficacy of speculative side-channel attacks. This is a temporary
> measure until other mitigations are in place.

[https://sites.google.com/a/chromium.org/dev/Home/chromium-
se...](https://sites.google.com/a/chromium.org/dev/Home/chromium-
security/ssca)

------
userbinator
Perhaps high-resolution timing needs to be a permission and not a "right",
just like access to location or webcam data.

~~~
mulmen
Can the user be expected to make the right choice there? I have no problem
deciding if Uber, a local restaurant or a news site need my location or camera
data. I have no idea why they would need high precision timing data or even
what "high precision" is. Maybe it's reasonable, maybe it isn't but it's not
as easy to decide from the user's shoes as location/camera.

~~~
discoursism
Most of the time, they won't need it. When they do, they'll need to make the
case to you explicitly. Some phone apps currently do this when they need a
non-obvious permission.

~~~
kbsletten
I think that the point is that most users can't be expected to understand the
risks present in allowing a high resolution timer. It's a very nuanced
decision, unlike camera and storage and location.

~~~
cptskippy
As a web developer, I am not entirely sure why a web app necessarily needs
high precision timers.

~~~
mrep
I'm developing a website that will require somewhat high frequency timing to
account for network latency but I think standard getTime is accurate enough
with millisecond accuracy which I think will satisfy my requirements (I still
need to test this though).

I can't think of something that needs microsecond level timing though.

~~~
pault
A browser based DAW/soft-synth?

~~~
cptskippy
That's one of those things that seems better suited to being a native App.

I realize there's a whole group of people who want to make the web browser as
powerful as native Apps but I for one do not.

~~~
pault
I agree; I would like to see a move away from trying to cram everything into a
browser app, and towards adding better connectivity and community features to
native apps.

------
contrarian_
This is basically an arms race. As long as the fundamental issue is not fixed
and all silicon replaced, there will always be people coming up with new ways
of exploiting the Spectre vulnerability in unexpected ways.

------
mehrdadn
Shall we now have a new website permission for timers or at least high-
precision timers? (It will be _quite_ fun to get end-users to understand the
ramifications of such a thing...)

~~~
zastrowm
Has there ever been discussion about a permission for "running as an app" that
would make a distinction between web pages and apps? I like that the web gets
more features that allow apps to run cross-platform, but I don't fully
understand why we make no distinction between pages and apps.

------
ec109685
I wonder if this part of the reason why Google added Site Isolation as
documented here: [https://securityboulevard.com/2017/12/google-chrome-
update-f...](https://securityboulevard.com/2017/12/google-chrome-update-
focuses-enterprise-security/)

~~~
anonymfus
Yes:

[https://support.google.com/faqs/answer/7622138#chrome](https://support.google.com/faqs/answer/7622138#chrome)

~~~
MBCook
I read on Twitter earlier today that they were working on site isolation for
six months before they found out about this.

Certainly shows why it’s useful though.

------
anonymfus
If instead of measuring time directly attacker would try to increment a
counter in a loop in another thread, would they get enough accuracy and
precision for the attack to work?

~~~
simcop2387
That's exactly what the shared buffer array thing is about. You can use a
webworker to do exactly that and still get accurate enough timing to do
accomplish this.

------
hirsin
Not being familiar with the usage of SharedArrayBuffer, is disabling it the
nuclear option (eg bad for everyone involved and clearly not the best option
if others existed)?

I see over 100 pages of commits on github referencing it, which tells me it's
not exactly rare?

~~~
Game_Ender
High performance applications need to share memory between threads. That
feature let you do it in JS, and is the basis of the future shared memory
multithreading feature in Web Assembly.

So if you want the next Photoshop or Final Cut Pro to be browser based we’ll
need to make it work securely.

~~~
ec109685
Seems like virtualization is the way to go for JavaScript. Hypervisors such as
XEN in HVM mode with modern processors don’t result in a large performance
penalty, so I imagine Chrome will gravitate towards it for running untrusted
code.

~~~
pcwalton
If running JS (that can access the DOM) in a separate process from the
renderer were feasible, browsers would have done it long ago.

~~~
devit
You just need to run it in a process without any secret data from other
origins or the browser/system.

That seems feasible without significant performance loss in most cases.

There is still a fingerprinting issue though that might not be possible to
fully remove without huge performance cost.

~~~
contrarian_
Process isolation does not prevent Spectre. In theory, you can carry out
Spectre over the network.

------
scottshea
I am very curious about Yehuda Katz's question on CSRF attacks and GET
requests:
[https://twitter.com/wycats/status/948812652997885952](https://twitter.com/wycats/status/948812652997885952)

------
mrep
Does anyone know how trustworthy client time accuracies are accounting for
clock skews?

After a bunch of google searches, I have not found anything suggesting how
accurate clocks are for clients besides Charlies algorithm [0] (I want to know
UTC time/epoch... whatever from each client so i can compare them) which I am
concerned about adopting due to the wiki page assuming a high quality network.

[0]:
[https://en.wikipedia.org/wiki/Cristian%27s_algorithm](https://en.wikipedia.org/wiki/Cristian%27s_algorithm)

~~~
chrismorgan
These timing attacks are all about local time deltas, not absolute times,
because it’s measuring the CPU caches, not anything to do with the network.
Things like “this operation took 5µs, which suggests that the data it was
accessing was/was not cached”.

------
gpm
This says

> Specifically, in all release channels, starting with 57:

Firefox 57 was released nov 14, did it already include those changes?

~~~
H4CK3RM4N
I think that means it's been pushed to the release channel.

------
jakozaur
Simple explanation: one of the attack is based on speculative out of order
execution to access memory you don’t own.

Though cpu cleans registry, it doesn’t clean up cache. So later through timing
you can gain knowledge about something you shouldn’t know.

That is why, reducing timers precision can help

~~~
contrarian_
If it cleans cache, you can detect the evicted address tag.

------
thrillgore
So what are the odds the NSA was aware of this?

~~~
deno
No one can blame them for knowing… The real question is if Intel knew and were
they in any way incentivised not to fix it sooner. It would be very “easy” to
justify not fixing a bug that went undetected for let’s say 10 years…

If there ever was NSA hardware bug this is how it would look like. I doubt
we’ll ever know.

------
nachtigall
I wonder if and how Waterfox or Palemoon can keep up with these security
issues? (Disclosure: I am a Firefox Nightly user)

~~~
rebelwebmaster
The performance.now() patch changed one line of code, so backporting that
shouldn't be hard. The SharedArrayBuffer change is just flipping a pref, so
that should be easy as well (assuming it's even supported - isn't Palemoon a
pretty ancient fork of Firefox? Even Mozilla's most recent ESR release doesn't
have SAB enabled by default).

------
therealmarv
And Chrome? Do they do similar things NOW?

~~~
stupidcar
Yes

[https://sites.google.com/a/chromium.org/dev/Home/chromium-
se...](https://sites.google.com/a/chromium.org/dev/Home/chromium-
security/ssca)

------
dmateos
If you stack kernels like

Hypervisor Guest OS

Is there double the performance hit of all these attack fixes?

------
microcolonel
And this is why running arbitrary software from people you've never heard of
will _always_ suck more.

------
zerken
Is latest ESR version (52.5.3) of Firefox patched?

I can't invoke SharedArrayBuffer for sure but what about the resolution of
performance.now()?

~~~
rebelwebmaster
The performance.now() change is due to ship to ESR users with the 52.6 release
on January 23.

------
masswerk
For the interim, may it be a wise idea to include an inlined script at the
very top of any page which includes untrusted 3rd party code, in order to
overwrite the Performance tools by a wrapper? By adding some random to the
real numbers this may help mitigating effects ...

E.g.,

    
    
      (function() {
          var global = (function() { return this; }).call(),
              _Performance = global.Performance,
              _performance = global.performance;
          global.Performance = /* ... snip ... */;
          global.performance = /* ... snip ... */;
      })();
    

[Edit]: This could be injected by a browser-plugin on the user's side, as
well.

~~~
masswerk
Note: "May it be a wise idea ... ?" is an open question, meant to start a
discussion. No need for down-voting, just answer or ignore it. :-)

