resource:// URIs leak information

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

Trac:
Username: holizz

added TorBrowserTeam201607R component::applications/tor browser owner::tbb-team priority::very high reporter::holizz resolution::fixed severity::major status::closed tbb-fingerprinting tbb-firefox-patch tbb-rebase-regression tbb-testcase type::defect labels

Trac:
Cc: N/A to g.koppen@jondos.de

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/

Trac:
Cc: g.koppen@jondos.de to g.koppen@jondos.de, griffinboyce@gmail.com

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 "re/" 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.

Trac:
Username: keb

Can confirm this as well.

Trac:
Cc: g.koppen@jondos.de, griffinboyce@gmail.com to g.koppen@jondos.de, griffinboyce@gmail.com, adrelanos@riseup.net
Owner: erinn to mikeperry
Status: new to assigned

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.

Trac:
Keywords: N/A deleted, tbb-fingerprinting added
Component: Tor bundles/installation to Firefox Patch Issues

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 re//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 re//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.

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

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.

Trac:
Priority: normal to major
Keywords: N/A deleted, tbb-rebase-regression added

I have been playing around with accessing the js files in re/ 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 re/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.

Trac:
Username: dservos

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 re/ 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).

Thanks for the test script!

Trac:
Cc: g.koppen@jondos.de, griffinboyce@gmail.com, adrelanos@riseup.net to gk, griffinboyce@gmail.com, adrelanos@riseup.net
Keywords: N/A deleted, tbb-testcase added
Status: assigned to new

Trac:
Keywords: N/A deleted, tbb-firefox-patch added

Trac:
Component: Firefox Patch Issues to Tor Browser
Owner: mikeperry to tbb-team

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.

Trac:
Sponsor: N/A to N/A
Severity: N/A to Normal

Opened 3 years ago

Why isn't it fixed yet?

Trac:
Severity: Normal to Major
Priority: High to Very High

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

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.

Can you ask Mozilla to change exposing re[/](/) URIs opt-in for each extension via manifests (because some non-TBB extensions need it) and eliminate re[/](/) 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.

Trac:
Reviewer: N/A to N/A

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

((removed my ancient email address))

Trac:
Cc: gk, griffinboyce@gmail.com, adrelanos@riseup.net to gk, adrelanos@riseup.net

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 re[/](/`) URLs for obvious reasons, so a content policy is required). Not sure what the Tor Browser policy is on licensing.

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

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.

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.

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.

Trac:
Keywords: N/A deleted, TorBrowserTeam201606R added
Status: new to needs_review

Now that #18914 (moved) 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!

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?

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).

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.

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.

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

I also made a test to see if I could use redirects from content to load re/ or chrome:// URIs into

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

Replying to arthuredelstein:

I also made a test to see if I could use redirects from content to load re/ or chrome:// URIs into

Trac:
Keywords: TorBrowserTeam201606R deleted, TorBrowserTeam201607R added

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

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

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

One more change to handle redirects properly.

Do nested schemes (view-[,](,) 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-[chrome://nonexistent/content/](chrome://nonexistent/content/) denied the same way as view-[chrome://torbutton/content/?](chrome://torbutton/content/?)

Replying to yawning:

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

One more change to handle redirects properly.

r=me

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.

Trac:
Cc: gk, adrelanos@riseup.net to gk, adrelanos@riseup.net, boklm

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.

Trac:
Username: nord-stream
Cc: gk, adrelanos@riseup.net, boklm to gk, adrelanos@riseup.net, boklm, nord-stream@ochaken.jp.eu.org

Trac:
Status: needs_review to assigned

Also see #19837 (moved)

That shipped in 6.5. We are done here.

Trac:
Resolution: N/A to fixed
Status: assigned to closed

See #21396 (moved).

It has been fixed in Firefox 57 https://bugzilla.mozilla.org/show_bug.cgi?id=863246

closed

mentioned in issue #17175 (moved)