Opened 2 years ago

Last modified 8 months ago

#16110 needs_review defect

Improve Time Resolution Defense

Reported by: mikeperry Owned by: mikeperry
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: tbb-fingerprinting-time-highres
Cc: gk, brade, mcs, lhansen, huseby Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Hovav Shacham and Keaton Mowery saw #1517 and emailed to point out some papers from the virtualization literature that have tried to deal with timing-based side channels. It turns out that simply reducing the granularity of the clock can still allow an adversary to extrapolate the true time by running a busy loop with a predictable operation in it. They provided a simple test that I updated and posted here https://people.torproject.org/~mikeperry/transient/tests/timingtest.html. It is able to recover the original time value with ~1-5ms accuracy.

They linked to this paper https://cseweb.ucsd.edu/~hovav/dist/xentimers.pdf, and suggested that the best approach would be:

Pick some nominal granularity x. Then define a distribution (normal?) with mean at x. Clocks available to the program only ever show an exact multiple of x, with a clock-edge on transition. But they are lies: Immediately after a clock edge, the monitor draws some value t out of the distribution with mean x, and then sets a time-t timer; when that timer fires, the clock shown to the program is increased by x, and the monitor draws a new value t and continues.

In other words, we'd still report 100ms steps, but change when we bump that step by +/- 50ms or so, based on a random value.

While I'm at it, I should also see how well using window.requestAnimationFrame and setTimeout can reconstruct the clock.

Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers. There's also a new animation API (https://developer.mozilla.org/en-US/docs/Web/API/AnimationPlayer).

Child Tickets

TicketSummaryOwner
#18273CSS animations provide high resolution timertbb-team
#18279Javascript setTimeout can be used for high resolution clocktbb-team

Change History (21)

comment:1 Changed 2 years ago by gk

  • Cc gk added

comment:2 Changed 2 years ago by mcs

  • Cc brade mcs added

comment:3 Changed 2 years ago by mikeperry

  • Keywords tbb-5.0a-highrisk added

Tag the set of things that are risky to debut in the 5.0-stable release without testing in a prior alpha.

comment:4 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201506 added

Ensure all tbb-5.0a items are on the June radar.

comment:5 Changed 2 years ago by mikeperry

  • Keywords MikePerry201506 added
  • Status changed from new to assigned

comment:6 in reply to: ↑ description ; follow-ups: Changed 2 years ago by gk

Replying to mikeperry:

Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers.

See #16340 which is/was for this investigation in particular.

comment:7 in reply to: ↑ 6 ; follow-up: Changed 2 years ago by mikeperry

Replying to gk:

Replying to mikeperry:

Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers.

See #16340 which is/was for this investigation in particular.

Also related: #13024, #16336.

comment:8 follow-up: Changed 2 years ago by mikeperry

According to https://developer.mozilla.org/en-US/docs/Web/API/Animation, the new animation API is prefed off with dom.animations-api.core.enabled. I checked a Firefox 38 install, and this pref is still false.

comment:9 in reply to: ↑ 8 ; follow-up: Changed 2 years ago by mikeperry

Replying to mikeperry:

According to https://developer.mozilla.org/en-US/docs/Web/API/Animation, the new animation API is prefed off with dom.animations-api.core.enabled. I checked a Firefox 38 install, and this pref is still false.

This pref might be a lie. I still see AnimationPlayer in my JS console. I'll need to write a proper test to try to use it...

comment:10 in reply to: ↑ 9 ; follow-up: Changed 2 years ago by mcs

Replying to mikeperry:

This pref might be a lie. I still see AnimationPlayer in my JS console. I'll need to write a proper test to try to use it...

It looks like that pref. should work. Are you sure your test document is not privileged? See:

http://mxr.mozilla.org/mozilla-esr38/source/dom/base/nsDocument.cpp#3311

I tested with Firefox 38.0.1 ESR on Mac OS with dom.animations-api.core.enabled=false and I only saw AnimationEvent. When I changed that pref. to true I saw a bunch more stuff:

AnimationTimeline
AnimationPlayer
AnimationEffect
Animation

Last edited 2 years ago by mcs (previous) (diff)

comment:11 in reply to: ↑ 10 Changed 2 years ago by mikeperry

Replying to mcs:

Replying to mikeperry:

This pref might be a lie. I still see AnimationPlayer in my JS console. I'll need to write a proper test to try to use it...

It looks like that pref. should work. Are you sure your test document is not privileged? See:

http://mxr.mozilla.org/mozilla-esr38/source/dom/base/nsDocument.cpp#3311

I tested with Firefox 38.0.1 ESR on Mac OS with dom.animations-api.core.enabled=false and I only saw AnimationEvent. When I changed that pref. to true I saw a bunch more stuff:

AnimationTimeline
AnimationPlayer
AnimationEffect
Animation

Ah, right, I was only testing about: windows, which were privileged. Apparently the webidl for these APIs has a special check for a function that enables access to chrome code. Thanks.

comment:12 in reply to: ↑ 7 Changed 2 years ago by mikeperry

Replying to mikeperry:

Replying to gk:

Replying to mikeperry:

Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers.

See #16340 which is/was for this investigation in particular.

Also related: #13024, #16336.

I handled #16340 using the same approach as #1517. I also handled #13024 and #16336 using the prefs. I am leaving this ticket open to apply a better defense as described in the description at a later point, and/or to relax the amount we clip by.

comment:13 Changed 2 years ago by mikeperry

  • Keywords TorBrowserTeam201507 added; TorBrowserTeam201506 removed

Move over remaining June items to July

comment:14 Changed 2 years ago by mikeperry

  • Keywords MikePerry201507 added; MikePerry201506 removed

Move my tickets over for July

comment:15 Changed 2 years ago by mikeperry

  • Keywords ff38-esr tbb-5.0a-highrisk TorBrowserTeam201507 MikePerry201507 removed

Taking this off the radar for now, as it is a general fingerprinting enhancement and no longer specific to FF38.

comment:16 Changed 20 months ago by lhansen

  • Cc lhansen added
  • Severity set to Normal

comment:17 Changed 16 months ago by gk

http://jcarlosnorte.com/security/2016/03/06/advanced-tor-browser-fingerprinting.html points to some example code and methods that bypass our current defense

comment:18 Changed 11 months ago by gk

Okay, David Kohlbrenner's and Hovav Shacham's paper is public now: Trusted Browsers for Uncertain Times (https://www.usenix.org/system/files/conference/usenixsecurity16/sec16_paper_kohlbrenner.pdf)

comment:19 Changed 9 months ago by mikeperry

  • Cc huseby added
  • Status changed from assigned to needs_review

Note: Dave pointed out that paper also came with an implementation that we could potentially take for Tor Browser: https://github.com/dkohlbre/gecko-dev (search for branch fuzzyfox - there are a few).

Dave is going to run it on Mozilla try to test for performance regressions. Adding him to Cc to report back on results there.

comment:20 Changed 9 months ago by gk

FWIW: https://github.com/dkohlbre/gecko-dev/tree/fuzzyfox-explicitclocks is the latest one David Kohlbrenner pointed out. He said two days ago that hooking into randomness is still missing and he is going to run a try build once this is resolved.

comment:21 in reply to: ↑ 6 Changed 8 months ago by bugzilla

Replying to gk:

Replying to mikeperry:

Firefox 38 also added a bunch more time sources to window.Performance, and also added Performance API support to WebWorkers and SharedWorkers.

See #16340 which is/was for this investigation in particular.

API was added specially to gain sub-ms resolution, and you set it to 100 ms, thus made fully useless.
Authors tried to cope with some issues: https://www.w3.org/TR/hr-time/#privacy-security.

Note: See TracTickets for help on using tickets.