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]
:
: Andy McKay [:andym]
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 User image 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 User image moz_bug_r_a4 2011-03-28 08:12:45 PDT
Created attachment 522366 [details]
testcase

This works on trunk.
Comment 2 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image 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 User image Dave Townsend [:mossop] 2011-04-08 10:36:47 PDT
Landed: http://hg.mozilla.org/mozilla-central/rev/3578f5b22f6b
Comment 13 User image 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 User image 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 User image 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.