Re: [tor-bugs] #9308 [Firefox Patch Issues]: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and Windows

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#9308: JavaScript's BrowserFeedWriter() leaks installation paths on OS X and
Windows
-------------------------------------+-------------------------------------
     Reporter:  cypherpunks          |      Owner:  mikeperry
         Type:  defect               |     Status:  needs_review
     Priority:  critical             |  Milestone:
    Component:  Firefox Patch        |    Version:
  Issues                             |   Keywords:  tbb-fingerprinting,
   Resolution:                       |  tbb-easy, interview,
Actual Points:                       |  GeorgKoppen201404R
       Points:                       |  Parent ID:
-------------------------------------+-------------------------------------

Comment (by gk):

 Replying to [comment:25 arthuredelstein]:
 > I've investigated the `precompile startup cache` mechanism a little
 more. I ran two builds, one with `precompile_cache.js` turned off, and one
 with it turned on.
 >
 > The zip file `TorBrowser.app/Contents/MacOS/browser/omni.ja` contains
 two extra directories, `jsloader` and `jssubloader` that are present only
 if `precompile_cache.js` has been run. Inside the directory
 `jsloader/resource/app/components/' are a number of .js files, which are
 (contrary to convention) binary files. These binary .js files are
 apparently compiled versions of JavaScript sources with the same name. One
 such compiled file is
 `omni.ja!jsloader/resource/app/components/FeedWriter.js`.
 >
 > If these compiled .js files are removed from `omni.ja`, then
 TorBrowser.app reverts to leaking the file location of an uncompiled
 version of FeedWriter.js as an absolute `file://` URI. Conversely, if we
 don't precompile the cache, but add a compiled version of `FeedWriter.js`
 to the same location in omni.ja, then TorBrowser.app displays the
 `resource://` URI that does not leak the install path.

 And what happens if we don't precompile the cache but add an *uncompiled*
 version to resource/app/components? If the Tor Browser is not complaining
 then we probably have the easiest solution to our problem.

 > So one way to stop the leakage would be to take compiled versions of
 `FeedWriter.js` and similar files, and supplement the omni.ja file.
 Unfortunately, we need xpcshell to produce these compiled versions, and a
 linux-native xpcshell is not available in a cross-compiled version of the
 tor-browser.git. We could borrow the compiled .js files from the linux
 build, but then building the Mac or Windows build would require anyone
 building to run a full linux build, essentially doubling the build time. I
 don't see any other way to produce the compiled versions of
 `FeedWriter.js`, however.

 What about Mike's idea of doing a python stub that is doing the pre-
 compilation? And what about compiling those .js files once and ship them
 as resources via the gitian versions files?

 > An alternative would be to try to re-write the `file://` URIs to
 `resource://` URIs in the thrown exceptions. A class,
 nsResProtocolHandler, stores a mapping from `resource://` URIs to
 `file://` URIs, so we might be able to add some code that reverses this
 mapping so that we can do the re-writing. Such a patch is perhaps not too
 likely to be adopted by Mozilla. On the other hand, since the two known
 bugs (`BrowserFeedWriter` and `sidebar.addSearchEngine`) are not present
 in ESR31, we could simply create a temporary patch that can be discarded
 when rebasing of TBB to ESR31 happens.

 Sounds complicated but if it works why not (I have not looked at the code
 to estimate how large that patch would have to be, so it might instead be
 quite easy to provide one). BTW: Are we sure there are no other components
 exposed to the website that could cause similar issues?

 > Any advice on which alternative to choose? Thanks!

 Given that this is obsolete with ESR 31 choosing the fastest way to solve
 this ticket seems to be a good approach. :)

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/9308#comment:26>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs