Bug 645699 (CVE-2011-2370)

A non-whitelisted site can trigger xpinstall

VERIFIED FIXED in Firefox 5

Status

()

Toolkit
Add-ons Manager
--
major
VERIFIED FIXED
7 years ago
6 years ago

People

(Reporter: moz_bug_r_a4, Assigned: mossop)

Tracking

2.0 Branch
mozilla5
Points:
---
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(firefox5 fixed, blocking2.0 -, status2.0 wanted, status1.9.2 unaffected, status1.9.1 unaffected)

Details

(Whiteboard: [sg:low])

Attachments

(3 attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Created attachment 522366 [details]
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
(Reporter)

Comment 3

7 years ago
(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?
(Reporter)

Comment 7

7 years ago
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.
(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)

Updated

7 years ago
Assignee: nobody → dtownsend
(Assignee)

Comment 9

7 years ago
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.
Attachment #523069 - Flags: review?(robert.bugzilla)

Comment 10

7 years ago
[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]
Attachment #523069 - Flags: review?(robert.bugzilla) → review+
(Assignee)

Comment 11

7 years ago
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?
(Assignee)

Comment 12

7 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/3578f5b22f6b
Status: NEW → RESOLVED
blocking2.0: --- → ?
Last Resolved: 7 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
(Assignee)

Updated

7 years ago
Target Milestone: --- → mozilla2.2
(Assignee)

Comment 13

6 years ago
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?

Comment 14

6 years ago
While it would be good to have, sg:low doesn't meet the bar for Macaw. This will be fixed in 5
blocking2.0: ? → -

Updated

6 years ago
Attachment #523069 - Flags: approval2.0? → approval2.0-
(Assignee)

Updated

6 years ago
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
status1.9.1: --- → unaffected
status1.9.2: --- → unaffected
status2.0: --- → wanted
status-firefox5: --- → fixed
Alias: CVE-2011-2370
Group: core-security
You need to log in before you can comment on or make changes to this bug.