Last Comment Bug 645699 - (CVE-2011-2370) A non-whitelisted site can trigger xpinstall
(CVE-2011-2370)
: A non-whitelisted site can trigger xpinstall
Status: VERIFIED FIXED
[sg:low]
:
Product: Toolkit
Classification: Components
Component: Add-ons Manager (show other bugs)
: 2.0 Branch
: All All
: -- major (vote)
: mozilla5
Assigned To: Dave Townsend [:mossop]
:
:
Mentors:
Depends on:
Blocks: 643773
  Show dependency treegraph
 
Reported: 2011-03-28 08:09 PDT by moz_bug_r_a4
Modified: 2011-07-12 08:24 PDT (History)
9 users (show)
dtownsend: in‑testsuite+
dtownsend: in‑litmus-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
-
wanted
unaffected
unaffected


Attachments
testcase (378 bytes, text/html)
2011-03-28 08:12 PDT, moz_bug_r_a4
no flags Details
testcase 2 - without the trick (359 bytes, text/html)
2011-03-28 09:43 PDT, moz_bug_r_a4
no flags Details
patch rev 1 (7.97 KB, patch)
2011-03-30 11:30 PDT, Dave Townsend [:mossop]
robert.strong.bugs: review+
christian: approval2.0-
Details | Diff | Splinter Review

Description moz_bug_r_a4 2011-03-28 08:09:57 PDT
http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions-content.js#93

93     install: function(aArgs, aCallback) {
94       if (!aArgs || typeof aArgs != "object")
95         throw new Error("Incorrect arguments passed to InstallTrigger.install()");
96 
97       var params = {
98         installerId: this.installerId,
99         mimetype: "application/x-xpinstall",
100         referer: this.window.location.href,
101         uris: [],
102         hashes: [],
103         names: [],
104         icons: [],
105       };

this.window is a SJOW.  And it's possible to redefine window.location.  Thus,
content code can control this.window.location.href.
Comment 1 moz_bug_r_a4 2011-03-28 08:12:45 PDT
Created attachment 522366 [details]
testcase

This works on trunk.
Comment 2 Boris Zbarsky [:bz] (still a bit busy) 2011-03-28 08:36:30 PDT
> this.window is a SJOW.

Gah.  Why?  :(

> 100         referer: this.window.location.href,

Yeah, window is not an XrayWrapper, that's just broken.
Comment 3 moz_bug_r_a4 2011-03-28 08:49:27 PDT
(In reply to comment #2)
> > this.window is a SJOW.
> 
> Gah.  Why?  :(
> 

http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/content/extensions-content.js#247

247     window.wrappedJSObject.__defineGetter__("InstallTrigger", function() {
...
253       delete window.wrappedJSObject.InstallTrigger;
254       var installTrigger = createInstallTrigger(window.wrappedJSObject);
255       window.wrappedJSObject.InstallTrigger = installTrigger;
256       return installTrigger;
257     });

We pass window.wrappedJSObject to createInstallTrigger.
Comment 4 Boris Zbarsky [:bz] (still a bit busy) 2011-03-28 08:51:08 PDT
Well, yes.  I understand why it's happening on a code level.  My question was why we're doing that.
Comment 5 Henrik Skupin (:whimboo) 2011-03-28 09:07:22 PDT
This testcase doesn't work for me when you remove addons.mozilla.org from the whitelist in the preferences first. I don't see an Install Software dialog on each of the platforms. So what are your initial steps to get this failing?
Comment 6 Boris Zbarsky [:bz] (still a bit busy) 2011-03-28 09:15:47 PDT
Henrik, addons.mozilla.org is in the whitelist by default, so we're vulnerable by default, no?
Comment 7 moz_bug_r_a4 2011-03-28 09:43:55 PDT
Created attachment 522382 [details]
testcase 2 - without the trick

(In reply to comment #5)
> So what are your initial steps to get this failing?

This testcase shows that bugzilla.mozilla.org can't trigger xpinstall without
the trick.
Comment 8 Henrik Skupin (:whimboo) 2011-03-28 12:40:55 PDT
(In reply to comment #6)
> Henrik, addons.mozilla.org is in the whitelist by default, so we're vulnerable
> by default, no?

Ok, something was broken early today on my system. Now I'm able to reproduce the reported behavior on OS X.
Comment 9 Dave Townsend [:mossop] 2011-03-30 11:30:35 PDT
Created attachment 523069 [details] [diff] [review]
patch rev 1

This stops us using the unwrapped window and also switches to using document.documentURIObject throughout. The testcase verifies that the page cannot bypass the whitelist anymore.
Comment 10 Jesse Ruderman 2011-03-30 19:42:56 PDT
[sg:low] because you still get the dialog. You just bypass the infobar that non-AMO sites get.  The infobar is more of an anti-annoyance measure than a security measure.  You can attack the infobar with a UI timing attack anyway. Or, if your goal is to get the victim to install an AMO-hosted extension, you can attack the AMO web site in a similar manner.
Comment 11 Dave Townsend [:mossop] 2011-04-01 09:25:39 PDT
If I land this as-is it's going to be pretty obvious what the issue is here. I assume because this is only sg:low that that isn't a big problem?
Comment 12 Dave Townsend [:mossop] 2011-04-08 10:36:47 PDT
Landed: http://hg.mozilla.org/mozilla-central/rev/3578f5b22f6b
Comment 13 Dave Townsend [:mossop] 2011-04-11 20:26:08 PDT
Comment on attachment 523069 [details] [diff] [review]
patch rev 1

Requesting approval to land this for the next 4.0.x release to close this small whole.
Comment 14 christian 2011-04-13 10:54:34 PDT
While it would be good to have, sg:low doesn't meet the bar for Macaw. This will be fixed in 5
Comment 15 Henrik Skupin (:whimboo) 2011-05-13 05:03:54 PDT
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110512 Firefox/5.0a2

Note You need to log in before you can comment on or make changes to this bug.