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
Activity
Trac:
Cc: N/A to g.koppen@jondos.deI 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: kebCan 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 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-
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 eliminatere[/](/) exposure in Firefox core? This is important upstream too. It is actually one of the most critical holes in Firefox (now withComponentsdeprecated 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/AI have a workaround for this. Can you please look at https://addons.mozilla.org/en-US/firefox/addon/no-resource-uri-leak/ ?