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)
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"
Reporter | ||
Comment 1•10 years ago
|
||
This might be relevant for bug 927061.
Comment 2•10 years ago
|
||
I doubt this has anything to do with cross compilation.
Updated•10 years ago
|
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
Comment 3•10 years ago
|
||
And this should, in fact, be fixed by bug 983845.
Comment 4•10 years ago
|
||
In 31.0a1: unknown error:ReferenceError: BrowserFeedWriter is not defined
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Comment 5•10 years ago
|
||
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]
Updated•5 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•