Closed Bug 645699 (CVE-2011-2370) Opened 9 years ago Closed 9 years ago

A non-whitelisted site can trigger xpinstall

Categories

(Toolkit :: Add-ons Manager, defect, major)

2.0 Branch
defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla5
Tracking Status
firefox5 --- fixed
blocking2.0 --- -
status2.0 --- wanted
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: moz_bug_r_a4, Assigned: mossop)

References

Details

(Whiteboard: [sg:low])

Attachments

(3 files)

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.
Attached file testcase
This works on trunk.
> this.window is a SJOW.

Gah.  Why?  :(

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

Yeah, window is not an XrayWrapper, that's just broken.
Component: Security → Add-ons Manager
Product: Core → Toolkit
QA Contact: toolkit → add-ons.manager
(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.
Well, yes.  I understand why it's happening on a code level.  My question was why we're doing that.
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?
Henrik, addons.mozilla.org is in the whitelist by default, so we're vulnerable by default, no?
(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.
(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.
Severity: normal → major
OS: Windows XP → All
Hardware: x86 → All
Version: Trunk → 2.0 Branch
Assignee: nobody → dtownsend
Attached patch patch rev 1Splinter Review
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.
Attachment #523069 - Flags: review?(robert.bugzilla)
[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.
Whiteboard: [sg:low]
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?
Landed: http://hg.mozilla.org/mozilla-central/rev/3578f5b22f6b
Status: NEW → RESOLVED
blocking2.0: --- → ?
Closed: 9 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.2
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.
Attachment #523069 - Flags: approval2.0?
While it would be good to have, sg:low doesn't meet the bar for Macaw. This will be fixed in 5
blocking2.0: ? → -
Attachment #523069 - Flags: approval2.0? → approval2.0-
Blocks: 643773
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110512 Firefox/5.0a2
Status: RESOLVED → VERIFIED
Alias: CVE-2011-2370
Group: core-security
You need to log in before you can comment on or make changes to this bug.