Opened 3 years ago

Closed 2 years ago

Last modified 21 months ago

#19479 closed defect (fixed)

Document.timeline.currentTime leaks ms-resolution clock in Firefox >=48

Reported by: arthuredelstein Owned by: rah
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords: ff52-esr, tbb-fingerprinting-time-highres
Cc: arthuredelstein, brade, mcs Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Child Tickets

Attachments (2)

0001-Bug-19479-Reduce-clock-leakage-from-Document.timelin.patch (1.5 KB) - added by rah 2 years ago.
Second patch
test.html (510 bytes) - added by rah 2 years ago.
Test HTML file

Download all attachments as: .zip

Change History (14)

comment:1 Changed 3 years ago by gk

Keywords: tbb-7.0-must added

comment:2 Changed 3 years ago by gk

Keywords: TorBrowserTeam201703 added

Getting those tickets on our March radar as well.

comment:3 Changed 3 years ago by arthuredelstein

Keywords: ff59-esr added; ff52-esr tbb-7.0-must TorBrowserTeam201703 removed

Turns out this API is still only exposed in Firefox Nightly or chrome code. So I think we can postpone patching it until the next ESR.

comment:4 Changed 2 years ago by arthuredelstein

Cc: arthuredelstein added

comment:5 Changed 2 years ago by mcs

Cc: brade mcs added

comment:6 Changed 2 years ago by rah

Owner: changed from tbb-team to rah
Status: newaccepted

comment:7 in reply to:  3 ; Changed 2 years ago by rah

Hi all,

I've created an initial patch, attached. This is following the strategy described in entry 15, Timing-based Side Channels, of the "Specific Fingerprinting Defenses in the Tor Browser" list under section 4.6, Cross-Origin Fingerprinting Unlinkability, of The Design and Implementation of the Tor Browser:

https://www.torproject.org/projects/torbrowser/design/#fingerprinting-linkability

The patch is against the tor-browser-52.2.0esr-7.5-1 branch. I've created a small HTML document for testing, also attached. However, as noted above, this functionality is only exposed in Firefox Nightly and the test HTML reports that document.timeline is not defined when run in the tor-browser branch.

I'm wondering whether there is a simple switch to activate this functionality in the tor-browser branch? Or is it a matter of the code not being there yet?

Thanks,

Bob Ham

comment:8 in reply to:  7 Changed 2 years ago by gk

Replying to rah:

I'm wondering whether there is a simple switch to activate this functionality in the tor-browser branch? Or is it a matter of the code not being there yet?

I think you should have access to document.timeline if you switched dom.animations-api.core.enabled to true. At least for me it was available to content then as well.

Changed 2 years ago by rah

Attachment: test.html added

Test HTML file

comment:9 Changed 2 years ago by rah

Replying to gk:

I think you should have access to document.timeline if you switched dom.animations-api.core.enabled to true

That worked, thanks. I tested my patch in Firefox Nightly and it worked; the output of document.timeline.currentTime was clamped to 100ms. I then tested the patch in tor-browser and it also worked. However, when I tested tor-browser without my patch, I was surprised to find that I got the same behaviour. I used the same test with a binary download of the latest tor browser bundle and again, got the same behaviour. My patch is superfluous and in fact, this bug has already been fixed.

The DocumentTimeline Web Animations API interface inherits its currentTime property from AnimationTimeline. The get method for this property is bound to mozilla::dom::AnimationTimeline::GetCurrentTimeAsDouble(). This method in turn calls the virtual method GetCurrentTime(), which is implemented in mozilla::dom::DocumentTimeline. However, GetCurrentTimeAsDouble() uses AnimationUtils::TimeDurationToDouble() to convert the value returned by GetCurrentTime(). In commit 167f4e468d8458b6e69f54ba16aef066d3f08160, AnimationUtils::TimeDurationToDouble() was modified to clamp the value to 100ms. In fact, that commit includes a mochitest test which checks document.timeline.currentTime among others.

So, this bug was already fixed along with #16337.

comment:10 Changed 2 years ago by rah

Resolution: fixed
Status: acceptedclosed

comment:11 in reply to:  9 Changed 2 years ago by gk

Replying to rah:

Replying to gk:

I think you should have access to document.timeline if you switched dom.animations-api.core.enabled to true

That worked, thanks. I tested my patch in Firefox Nightly and it worked; the output of document.timeline.currentTime was clamped to 100ms. I then tested the patch in tor-browser and it also worked. However, when I tested tor-browser without my patch, I was surprised to find that I got the same behaviour. I used the same test with a binary download of the latest tor browser bundle and again, got the same behaviour. My patch is superfluous and in fact, this bug has already been fixed.

The DocumentTimeline Web Animations API interface inherits its currentTime property from AnimationTimeline. The get method for this property is bound to mozilla::dom::AnimationTimeline::GetCurrentTimeAsDouble(). This method in turn calls the virtual method GetCurrentTime(), which is implemented in mozilla::dom::DocumentTimeline. However, GetCurrentTimeAsDouble() uses AnimationUtils::TimeDurationToDouble() to convert the value returned by GetCurrentTime(). In commit 167f4e468d8458b6e69f54ba16aef066d3f08160, AnimationUtils::TimeDurationToDouble() was modified to clamp the value to 100ms. In fact, that commit includes a mochitest test which checks document.timeline.currentTime among others.

So, this bug was already fixed along with #16337.

Thanks for this analysis. Nice find!

comment:12 Changed 21 months ago by cypherpunks

Keywords: ff52-esr tbb-fingerprinting-time-highres added; ff59-esr tbb-fingerprinting removed
Note: See TracTickets for help on using tickets.