Opened 6 years ago

Closed 2 years ago

Last modified 19 months ago

#8725 closed defect (fixed)

resource:// URIs leak information

Reported by: holizz Owned by: tbb-team
Priority: Very High Milestone:
Component: Applications/Tor Browser Version:
Severity: Major Keywords: tbb-fingerprinting, tbb-rebase-regression, tbb-testcase, tbb-firefox-patch, TorBrowserTeam201607R
Cc: gk, adrelanos@…, boklm, nord-stream@… Actual Points:
Parent ID: Points:
Reviewer: Sponsor:

Description

Here's a bug in Firefox that may be able to identify users of Tor Browser Bundle:

https://bugzilla.mozilla.org/show_bug.cgi?id=863246

Child Tickets

TicketStatusOwnerSummaryComponent
#19837closedtbb-teamAudio/video player is blank in 6.5a2Applications/Tor Browser

Change History (47)

comment:1 Changed 6 years ago by gk

Cc: g.koppen@… added

comment:2 Changed 6 years ago by saint

Cc: griffinboyce@… added

I was able to duplicate this this bug using [1]. Somehow preventing outside resource_uri access or pretending to be a non-firefox browser would obviate this quirk.

[1] http://marcorondini.eu/research/resource_uri/

comment:3 Changed 6 years ago by keb

Source definition of the problematic uri
https://developer.mozilla.org/en-US/docs/Chrome_Registration#resource

Pretending to be not-firefox contradicts that torbrowser pretends to be mozilla.
Does firefox really need this "resource://" feature? It comes with a serious security warning. "Note that there are no security restrictions preventing web content from including content at resource: URIs, so take care what you make visible there." I.e. maybe better to lobby to remove it entirely from upstream.

comment:4 Changed 6 years ago by proper

Cc: adrelanos@… added
Owner: changed from erinn to mikeperry
Status: newassigned

Can confirm this as well.

comment:5 Changed 6 years ago by mikeperry

Component: Tor bundles/installationFirefox Patch Issues
Keywords: tbb-fingerprinting added

This issue is fixed in Aurora but not any released Firefox, correct?

If so, Mozilla may be waiting for FF22 to be officially released before backporting the fix to FF17-ESR.

Otherwise, someone should try to track down the actual bugzilla entry where they fixed this issue so we can apply that patch.

comment:6 Changed 6 years ago by gk

That issue is not fixed in Firefox21+. The only thing https://bugzilla.mozilla.org/show_bug.cgi?id=755724 does is to break the test on http://marcorondini.eu/research/resource_uri/ as the latter relies on resource:///defaults/autoconfig/platform.js which seems not to be available anymore. But at least the locale is still extractable in a recent Nightly and therefore whether a TorBrowser is used as well, I guess. Additionally, there might still be a good chance that the platform is getting extracted, too, using some platform specific differences in resource:///defaults/preferences/firefox.js (if there are any). That said, https://bugzilla.mozilla.org/show_bug.cgi?id=863246 is probably a duplicate of https://bugzilla.mozilla.org/show_bug.cgi?id=503221 which Gregory Fleischer opened several years ago.

comment:7 Changed 6 years ago by mikeperry

Keywords: tbb-rebase-regression added
Priority: normalmajor

Ugh. This is probably due to the removal of the content policy due to the FF16 crash (#7078).

It would be nice if we could find a way to stop this access with a patch as opposed to a content policy.

Calling this major because there probably is quite a bit of info lurking in all these resource files. It might even be critical.

comment:8 Changed 5 years ago by dservos

I have been playing around with accessing the js files in resource:// and it looks like this issue is a bit worse now that when it was first reported. In the proof of concept on marcorondini.eu, it was only checked that #tor.js existed. I believe that it could not easily be read in the version of tor at the time as there was a few "#" comments at the top which caused javascript errors when read using a script tag. However, in the current version of tor, the file is now called 000-tor-browser.js and can easily be read using a method similar to that used in marcorondini.eu. This is rather bad, as 000-tor-browser.js contains the tor browser version number, platform and real language. This would let you make a finger print that is unique at least to the tor browser version + platform + language (maybe even the cpu arch, since there is a 64bit version for Linux).

I made a simple script on http://cs1.ca/ttest/dump.html witch dumps everything that can be read in resource://defaults/. Simply hashing this output would make for a good start at a finger print.

A temporary fix until it can be dealt with upstream might be to put a few "#"s at the top of each file. I think they are parsed out the way the browser normally reads the files but would cause javascript errors when accessed like in the script I posted. Definitely not a permanent solution but it might be better than nothing.

comment:9 Changed 5 years ago by saint

This can be bypassed in a couple of different ways (just off the top of my head).  One is by pretending to be a non-firefox browser (as mentioned above), which has some serious compatibility issues with sites that serve up different code to different browsers.  Another is to strip resource:// requests on pageload when possible. The extension set Disconnect does this for around a million users.  In Chrome, this would be dead simple with beforeload coupled with a background script but Firefox isn't impossible. 

Perhaps make a Firefox extension that sets an observer (using observer-service) to listen for http-on-modify-request (literally any request) which can detect url scheme/prefix.  Then block those requests.  Or respond to all of them with gibberish.

To some extent this is less of an issue because the Tor browser bundle user group is comparatively homogenous. A larger issue is that it's possible to detect extensions used and launch an exploit for only those users (again, less of an issue for TBB, but large issue for internet as a whole).

comment:10 Changed 5 years ago by gk

Cc: gk added; g.koppen@… removed
Keywords: tbb-testcase added
Status: assignednew

Thanks for the test script!

comment:11 Changed 5 years ago by erinn

Keywords: tbb-firefox-patch added

comment:12 Changed 5 years ago by erinn

Component: Firefox Patch IssuesTor Browser
Owner: changed from mikeperry to tbb-team

comment:13 Changed 3 years ago by cypherpunks

Severity: Normal

This test shows the bug still exists in current version of the TBB. If JS is enabled, the type of platform is leaked. Adversary can distinguish Windows and Linux users.

Maybe canvas have the same problem making unique fingerprint for everybody.

comment:14 Changed 3 years ago by cypherpunks

Opened 3 years ago

Why isn't it fixed yet?

comment:15 Changed 3 years ago by cypherpunks

Priority: HighVery High
Severity: NormalMajor

comment:16 Changed 3 years ago by bugzilla

gk, this is a tbb-rebase-regression, so what's about the current rebasing?

Last edited 3 years ago by bugzilla (previous) (diff)

comment:17 in reply to:  16 Changed 3 years ago by gk

Replying to bugzilla:

gk, this is a rebase regression, so what's about the current rebasing?

No, it is not a rebase regression (in case we are using this term the same way). It is an actual bug.

comment:18 Changed 3 years ago by cypherpunks

Can you ask Mozilla to change exposing resource:// URIs opt-in for each extension via manifests (because some non-TBB extensions need it) and eliminate resource:// exposure in Firefox core? This is important upstream too. It is actually one of the most critical holes in Firefox (now with Components deprecated in Web). TBB's OS mangling is only half-baked with this problem unresolved. So each anonymity
set is quite a bit smaller than imagined.

https://bugzilla.mozilla.org/show_bug.cgi?id=863246 is inactive now. It seems we need more attention from Mozilla.

comment:19 Changed 3 years ago by cypherpunks

I have a workaround for this.
Can you please look at https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/ ?

comment:20 Changed 3 years ago by saint

Cc: griffinboyce@… removed

((removed my ancient email address))

Last edited 3 years ago by saint (previous) (diff)

comment:21 in reply to:  19 Changed 3 years ago by yawning

Replying to cypherpunks:

I have a workaround for this.
Can you please look at https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/ ?

As far as I can tell the approach you're taking is the only way to do this (the http-on-modify-request event does not fire for resource:// URLs for obvious reasons, so a content policy is required). Not sure what the Tor Browser policy is on licensing.

comment:22 Changed 3 years ago by cypherpunks

Although the example add-on is GPL-3, I licensed the content policy code under MPL-2. Is MPL too restrictive? (Then we'll need to consider a BSD or the MIT/X11 license.) But the Mozilla codebase is under MPL anyway...
https://notabug.org/desktopd/no-resource-uri-leak/src/master/src/resource-filter

comment:23 in reply to:  22 Changed 3 years ago by yawning

Replying to cypherpunks:

Although the example add-on is GPL-3, I licensed the content policy code under MPL-2. Is MPL too restrictive? (Then we'll need to consider a BSD or the MIT/X11 license.) But the Mozilla codebase is under MPL anyway...
https://notabug.org/desktopd/no-resource-uri-leak/src/master/src/resource-filter

FWIW, the current torbutton license is https://gitweb.torproject.org/torbutton.git/tree/src/LICENSE (Which seems sort of historical). And I don't really care either way, but it's ultimately not my call, I just want this fixed.

My plan was to integrate it into torbutton, instead of having it be a separate addon, though I'll drop the idea if the browser developers tell me that this should be solved another way.

comment:24 Changed 3 years ago by yawning

https://git.schwanenlied.me/yawning/torbutton/commit/0deee1b15b0b7fb6551d17827dc9cdd604ff35b9

Was what I had in mind as far as how to integrate it into torbutton (Yes, it works). Hopefully a real browser developer will take over from here.

comment:25 Changed 3 years ago by yawning

Keywords: TorBrowserTeam201606R added
Status: newneeds_review

I pushed a change to also restrict chrome:// URIs, regardless of contentaccessible, per discussion with gk. It sort of sucks that certain addons will break, but they aren't the standard Tor Browser set.

I leave it up to the Tor Browser people if they want to take that commit or not.

comment:26 Changed 3 years ago by cypherpunks

Now that #18914 is fixed, this is an important remaining hole that needs an immediate fix. With this fixed, there will be no known locale leak as far as I know. -- Thanks!

comment:27 Changed 3 years ago by gk

The second one is that shouldLoad is not invoked for redirects. You only get one call, for the first URL requested. If you let it pass, it can redirect anywhere without you noticing it.

https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/Intercepting_Page_Loads

So, my first guess would be that redirects can bypass this blocking mechanism. Did anybody test this?

comment:28 in reply to:  27 Changed 3 years ago by yawning

Replying to gk:

The second one is that shouldLoad is not invoked for redirects. You only get one call, for the first URL requested. If you let it pass, it can redirect anywhere without you noticing it.

https://developer.mozilla.org/en-US/Add-ons/Overlay_Extensions/XUL_School/Intercepting_Page_Loads

So, my first guess would be that redirects can bypass this blocking mechanism. Did anybody test this?

I have not. If nsIWebProgressListener2 fire, at the right time for chrome/resource URLs that may be an option here (specifically we want the onRefreshAttempted() callback).

comment:29 Changed 3 years ago by cypherpunks

My original idea is that only privileged chrome:// or about: pages can initiate a redirect to the blocked resources. If there is no such redirecting URIs accessible from content, there should be no leaks.
However, testing is needed anyway.

comment:30 in reply to:  29 Changed 3 years ago by yawning

Replying to cypherpunks:

My original idea is that only privileged chrome:// or about: pages can initiate a redirect to the blocked resources. If there is no such redirecting URIs accessible from content, there should be no leaks.

After looking at the documentation and the relevant specs, I'm 99.9% sure you're correct.

XMLHttpRequest() will fail the same-origin check, since the request is not coming from internal to the Firefox code (requests dispatched from inside Firefox can bypass the check completely, but poorly written addons are not our problem).

Fetch() refuses to have anything to do with redirects to non-HTTP(s) scheme URLs. (See: 5.4 HTTP-redirect fetch).

However, testing is needed anyway.

Yeah.

comment:31 Changed 3 years ago by arthuredelstein

FWIW, I tested Yawning's branch and confirmed it prevents https://www.browserleaks.com/firefox from accessing the resource:/// files.

comment:32 Changed 3 years ago by arthuredelstein

I also made a test to see if I could use redirects from content to load resource:// or chrome:// URIs into <script> elements:

https://arthuredelstein.github.io/tordemos/resource-locale.html

In unpatched Firefox or TorBrowser, the redirects fail and the following error is shown in the Browser Console:

Security Error: Content at https://arthuredelstein.github.io/tordemos/resource-locale.html may not load or link to jar:file:///Applications/Firefox.app/Contents/Resources/browser/omni.ja!/defaults/preferences/webide-prefs.js.
Security Error: Content at https://arthuredelstein.github.io/tordemos/resource-locale.html may not load or link to jar:file:///Applications/Firefox.app/Contents/Resources/browser/omni.ja!/chrome/browser/content/browser/browser.xul.

Direct loading of any prefs.js file succeeds.

But with Yawning's branch, the direct loading is blocked as well. I also read over the patches and the code looks good to me, so I would be inclined to include it in torbutton. It would be nice to have the git subject line start with Bug 8725:.

Regarding Yawning's XXX comment, I think it is nice to have resource:/// URIs load in tabs for debugging purposes. So unless this introduces a vulnerability I would be inclined to leave it as is.

Ideally we would come up with a C++ Firefox patch that could be upstreamed. But to avoid delay I think this torbutton patch is a good stopgap.

comment:34 in reply to:  32 Changed 3 years ago by gk

Replying to arthuredelstein:

I also made a test to see if I could use redirects from content to load resource:// or chrome:// URIs into <script> elements:

https://arthuredelstein.github.io/tordemos/resource-locale.html

In unpatched Firefox or TorBrowser, the redirects fail and the following error is shown in the Browser Console:

Security Error: Content at https://arthuredelstein.github.io/tordemos/resource-locale.html may not load or link to jar:file:///Applications/Firefox.app/Contents/Resources/browser/omni.ja!/defaults/preferences/webide-prefs.js.
Security Error: Content at https://arthuredelstein.github.io/tordemos/resource-locale.html may not load or link to jar:file:///Applications/Firefox.app/Contents/Resources/browser/omni.ja!/chrome/browser/content/browser/browser.xul.

Yes, I am not concerned with redirects breaking due to security errors. I have not tested this but not including cross-origin loads might help here.

comment:35 Changed 3 years ago by gk

Keywords: TorBrowserTeam201607R added; TorBrowserTeam201606R removed

comment:36 Changed 3 years ago by arthuredelstein

Here's another variant (XHR of resource:/// URIs) that yawning's patch successfully defends against:

https://bugzilla.mozilla.org/show_bug.cgi?id=1120398

comment:37 Changed 3 years ago by yawning

https://git.schwanenlied.me/yawning/torbutton/commits/bug8725_take3

One more change to handle redirects properly.

comment:38 Changed 3 years ago by cypherpunks

Do nested schemes (view-source:, jar:, etc.) leak information about existing restricted resources? Although I tend to think those schemes are inaccessible from content, that does not necessarily guarantee no information leak.

Ex.
Is view-source:chrome://nonexistent/content/ denied the same way as view-source:chrome://torbutton/content/?

comment:39 in reply to:  37 Changed 3 years ago by arthuredelstein

Replying to yawning:

https://git.schwanenlied.me/yawning/torbutton/commits/bug8725_take3

One more change to handle redirects properly.

r=me

comment:40 Changed 3 years ago by mikeperry

Cc: boklm added

Couple points:

  1. I think it *might* have been better to use http-on-modify-request here rather than both the content policy and the response listener, but you might also not have as much information there about the source content url. Maybe this doesn't matter so much, since what we really want is a direct Firefox patch. The extra observers will have a perf cost, though.
  2. Given that we want to replace this by a direct patch, we should turn arthur's https://arthuredelstein.github.io/tordemos/resource-locale.html into a Tor Browser test of some kind to verify that future versions behave the same way. Boklm, can you handle that? Also, please add a test for https://trac.torproject.org/projects/tor/ticket/8725#comment:38 about the nested schemes. We should test that too.

Otherwise, I think this is OK, and I agree it is an improvement. For now, I will merge this into the torbutton master branch for TBB 6.5-alpha, since it may shake a few more issues loose.

comment:41 in reply to:  40 Changed 3 years ago by yawning

Replying to mikeperry:

  1. I think it *might* have been better to use http-on-modify-request here rather than both the content policy and the response listener, but you might also not have as much information there about the source content url. Maybe this doesn't matter so much, since what we really want is a direct Firefox patch. The extra observers will have a perf cost, though.

The CSP is required because http-on-modify-request events dont' fire for recourse:// urls, unfortunately.

comment:42 Changed 3 years ago by nord-stream

Cc: nord-stream@… added

comment:43 Changed 3 years ago by gk

Status: needs_reviewassigned

comment:44 Changed 3 years ago by mcs

Also see #19837

comment:45 Changed 2 years ago by gk

Resolution: fixed
Status: assignedclosed

That shipped in 6.5. We are done here.

comment:46 Changed 2 years ago by gk

See #21396.

comment:47 Changed 19 months ago by cypherpunks

Note: See TracTickets for help on using tickets.