Closed Bug 991522 Opened 10 years ago Closed 10 years ago

BrowserFeedWriter leaks its path to web content through JS exceptions

Categories

(Firefox Graveyard :: RSS Discovery and Preview, defect)

24 Branch
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: gk, Unassigned)

References

Details

If one is e.g. cross-compiling Firefox then this might leak the username of the user who runs that build.

STR: 

1) Take a cross-compiled Firefox
2) Put it somewhere into your home directory
3) visit: http://pseudo-flaw.net/tor/torbutton/browserfeedwriter-error.html

You'll get something like:

Date: Wed Apr  2 17:57:53 2014
found location: "jar:file:///Users/release/TorBrowserBundle_en-US.app/Contents/MacOS/TorBrowser.app/Contents/MacOS/browser/omni.ja!/components/FeedWriter.js"
This might be relevant for bug 927061.
I doubt this has anything to do with cross compilation.
Component: Build Config → RSS Discovery and Preview
Product: Core → Firefox
Summary: Cross-compiling may leak username in JS exceptions → BrowserFeedWriter leaks its path to web content through JS exceptions
And this should, in fact, be fixed by bug 983845.
In 31.0a1:
unknown error:ReferenceError: BrowserFeedWriter is not defined
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Depends on: 983845
x(In reply to Mike Hommey [:glandium] from comment #2)
> I doubt this has anything to do with cross compilation.

I investigated this bug in the Tor Browser, which is based on ESR 24. I found that adding `export CROSS_COMPILE=1` to the .mozconfig file causes this bug to appear. Specifically, the browser install path is leaked by exceptions thrown by
  new BrowserFeedWriter().close();
and
  window.sidebar.addSearchEngine("http://", "http://", null, null);

I found that the reason the CROSS_COMPILE flag is important is that it is checked in
  ./toolkit/mozapps/installer/packager.py .
If the flag is enabled, then packager.py avoids running the "precompile_cache.js' script with xpcshell. This avoidance makes sense to me, because in a cross-compiling situation, we haven't built a native version of xpcshell that can be run on the compile platform.

The "precompile_cache.js" script prevents this bug, because it assigns various JavaScript files that are part of the Firefox build to "resource://" URIs, so that when Firefox runs, these exception will expose the offending JavaScript file's location as a "resource://". If the precompilation step is skipped, then the absolute path of the JavaScript file is exposed in a "file://" URI.

Compare the two cases:

1. CROSS_COMPILE = 1 --> precompile_cache.js does not run
Web console input:
  new BrowserFeedWriter().close();

Result:
  [19:01:44.250] [Exception... "'[JavaScript Error: "this._document is null" {file: "jar:file:///Applications/TorBrowserBundle_en-US.app/Contents/MacOS/TorBrowser.app/Contents/MacOS/browser/omni.ja!/components/FeedWriter.js" line: 702}]' when calling method: [nsIFeedWriter::close]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: debugger eval code :: WCA_evalWithDebugger :: line 1"  data: yes]

vs

2. CROSS_COMPILE not set --> precompile_cache.js runs
Web console input:
  new BrowserFeedWriter().close();

Result:
  [Exception... "'[JavaScript Error: "this._document is null" {file: "resource://app/components/FeedWriter.js" line: 702}]' when calling method: [nsIFeedWriter::close]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: debugger eval code :: <TOP_LEVEL> :: line 1"  data: yes]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.