Page can obtain path to Mozilla installation or possibly profile by examining JavaScript exceptions




13 years ago
3 years ago


(Reporter: Met - Martin Hassman, Unassigned)


(Depends on: 1 bug, Blocks: 1 bug, {privacy, sec-want})

privacy, sec-want
Dependency tree / graph
Bug Flags:
blocking-aviary1.0 -
blocking1.9 -
wanted1.9 +
blocking1.8.1 -
blocking1.8.0.5 -

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:want] stepping-stone)


(1 attachment)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.7.3) Gecko/20040910
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; cs-CZ; rv:1.7.3) Gecko/20040910

I am not sure if this should be considered as security bug. If you don't think
so, open it.

Page which call window.sidebar.addSearchEngine() with bad agruments (bad suffix,
protocol) can catch the exception of the Mozilla code and from it obtain path to
the Mozilla installlation.

Problem is in the nsSidebar.js (in Mozilla and Firefox too) containing line:
this.promptService.alert(null, "Failed to add the search engine.");

there is missing the 3th alert argument (text of the dialog), which raises
expception e.g.:
[Exception... "Not enough arguments [nsIPromptService.alert]"  nsresult:
"0x80570001 (NS_ERROR_XPC_NOT_ENOUGH_ARGS)"  location: "JS frame ::
file:///C:/Program%20Files/ ::
anonymous :: line 266"  data: no]

HTML page can catch this exception and obtain the path of the problematic file
(i.e. the path of Mozilla installation).

Revealing the path to the nsSidebar.js is not probably critical problem, but
what if the exception raises in some extension in the user profile and the page
can catch path to the user profile (and the user login)?

So problem is propably more general. Should be the HTML page able to catch
exceptions from the Mozilla code? And if should, should it obtain a full text of
the expections (including file path)?

Reproducible: Always
Steps to Reproduce:

Comment 1

13 years ago
Created attachment 164547 [details]

Comment 2

13 years ago
Note that there are other ways that sidebar can throw exceptions, e.g.
sidebar.addPanel(null, null, null);
Perhaps that should be a chrome URI, not a file one?

Comment 4

13 years ago
nsSidebar.js doesn't live in chrome, it's a component.
I'm not too worried about revealing the installation directory (it's generally
in an easily guessed default location), but Met is absolutely right that this
could potentially reveal the profile location. Would require:

- user installs Firefox extension (profile-based)
- extension uses a javascript component (chrome js exceptions would just reveal
  that the extension exists)
- extension exposes their component to web content somehow -- probably rare

Then the attacker would also have to know of a local-file-stealing exploit for
the profile location to be useful. In limited situations just knowing the
OS-login name might be useful to an attacker and that would usually be revealed
(unless the user chose a non-default profile location, and that's not generally
possible in Firefox without secret command-line args).

One "fix" for this bug would be to prevent the sidebar component from throwing
exceptions into user scripts. That seems like the friendly thing to do in any
case for sidebar, but that doesn't fix the potential for this to occur in some
popular but badly coded extension. Rather we need to fix this at the JS
exception level somehow.

Blue skying: if the exception is going to put a file: url in there just list the
filename, but strip the rest of the path. That's a little severe and hurts
people trying to develop apps on their local disk. Could perhaps check whether
the top level script is priveged or not, or what scheme it came from. Or just
strip paths by default and let developers flip a pref to get full paths like the
plugin.expose_full_path pref.

Nominating for 1.0 just to get consideration, but without knowing of a specific
profile-installed extension that can be induced to throw an exception into web
content I don't think we need to take this kind of change so late. Good 1.1/1.8
Ever confirmed: true
Flags: blocking-aviary1.0?
Whiteboard: [sg:fix]

Comment 6

13 years ago
gonna work on this for the next release
Flags: blocking-aviary1.0? → blocking-aviary1.0-


12 years ago
Summary: nsSidebar.js - page can obtain path to Mozilla installation → Page can obtain path to Mozilla installation or possibly profile by examining JavaScript exceptions
Group: security
Keywords: privacy
Whiteboard: [sg:fix] → [sg:want] stepping-stone


12 years ago
Flags: testcase+

Comment 7

12 years ago
Also true for FF on Mac OS X
OS: Windows 2000 → All
Hardware: PC → All
Flags: blocking1.9a1?
Flags: blocking1.8.1?
Depends on: 268370
I marked this as blocked by bug 268370 because it fixes the specific case mentioned here, but re-reading this bug, I see that's it's looking for a general solution to the problem, so I'll revert that change.
No longer depends on: 268370

Comment 9

12 years ago
Information about the testcase was posted to Bugtraq list on May 22th listing it as PoC:

Original time stamp at posting mwntioned is May 21 2006 because of moderating process of Symantec.

Comment 10

12 years ago
also now posted as secunia (suite) and firefox
I've posted a 1.8.0-compatible branch patch for the one known case of this problem in bug 268370. I've posted a better patch for 1.8 and trunk in bug 338989.

Comment 12

12 years ago
Also true for Firefox 2.0a2 (Bon Echo) on Fedora Core 4, kernel 2.6.14-1.1653_FC4, j2sdk-1.5.0_05-1_FC4.
Could we have our exception objects implement nsISecurityCheckedComponent and do a CanAccess check from the caller principal to the filename URI?

For DOMException this could be tough because it has classinfo claiming it's a DOM object and therefore would short-circuit the nsISecurityCheckedComponent check, but maybe we can change said classinfo?


12 years ago
Flags: blocking1.8.0.5?
Flags: blocking1.9a1?
Flags: blocking1.9a1+
Flags: blocking1.8.1?
Flags: blocking1.8.1+
Flags: blocking1.8.0.5?
Flags: blocking1.8.0.5+
(In reply to comment #11)
> I've posted a 1.8.0-compatible branch patch for the one known case of this
> problem in bug 268370.

That's a perfectly fine fix that we want, but we should not claim it fixes this bug (I don't think it even fixes neil's comment 2 testcase).
(In reply to comment #14)
> (In reply to comment #11)
> > I've posted a 1.8.0-compatible branch patch for the one known case of this
> > problem in bug 268370.
> That's a perfectly fine fix that we want, but we should not claim it fixes
> this bug (I don't think it even fixes neil's comment 2 testcase).

You're right, I should have said "for one known case of this" instead of "for the one known case of this". It does not fix the case from comment 2. I'll post a patch that does, because it's a trivial fix, but getting a better general solution to this bug would obviously be better than trying to play whack-a-mole with all the places this can happen.
Depends on: 268370
With the only known instance fixed (bug 268370) we can push the more general solution out to a more appropriate place like trunk or 1.8 branch.
Flags: blocking1.8.0.5+ → blocking1.8.0.5-
Target Milestone: --- → mozilla1.8.1beta2
Not going to block on this for release of Firefox 2, but we'd take a baked patch if one comes to us (nominate for approval1.8.1)
Flags: blocking1.8.1+ → blocking1.8.1-
Flags: blocking1.9-
Whiteboard: [sg:want] stepping-stone → [sg:want] stepping-stone [wanted-1.9]
Blocks: 370018


11 years ago
Flags: in-testsuite+ → in-testsuite?
Flags: wanted1.9+
Whiteboard: [sg:want] stepping-stone [wanted-1.9] → [sg:want] stepping-stone

Comment 18

10 years ago
The following test case is not able to catch anything on trunk.

try {
catch(e) {

And the following is logged to the error console:

Error: Invalid argument passed to window.sidebar.addPanel: Unsupported panel URL.
Source File: file:///C:/Program%20Files/Mozilla%20Firefox%203%20Beta%203/components/nsSidebar.js
Line: 47

Is this bug still valid on trunk?
(In reply to comment #18)
> Is this bug still valid on trunk?

Yes, see comment 16. There may be other unknown errors that will expose similar problems, so we need a general solution, rather than relying on being able to identify all the potential problem areas.
Flags: blocking1.9a1+
Assignee: dveditz → nobody


8 years ago
Depends on: 503228
QA Contact: toolkit
Keywords: sec-want


5 years ago
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.