Closed
Bug 645699
(CVE-2011-2370)
Opened 14 years ago
Closed 14 years ago
A non-whitelisted site can trigger xpinstall
Categories
(Toolkit :: Add-ons Manager, defect)
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)
378 bytes,
text/html
|
Details | |
359 bytes,
text/html
|
Details | |
7.97 KB,
patch
|
robert.strong.bugs
:
review+
christian
:
approval2.0-
|
Details | Diff | Splinter Review |
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•14 years ago
|
||
This works on trunk.
![]() |
||
Comment 2•14 years ago
|
||
> 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•14 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.
![]() |
||
Comment 4•14 years ago
|
||
Well, yes. I understand why it's happening on a code level. My question was why we're doing that.
Comment 5•14 years ago
|
||
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•14 years ago
|
||
Henrik, addons.mozilla.org is in the whitelist by default, so we're vulnerable by default, no?
Reporter | ||
Comment 7•14 years ago
|
||
(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•14 years ago
|
||
(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•14 years ago
|
Assignee: nobody → dtownsend
Assignee | ||
Comment 9•14 years ago
|
||
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•14 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]
![]() |
||
Updated•14 years ago
|
Attachment #523069 -
Flags: review?(robert.bugzilla) → review+
Assignee | ||
Comment 11•14 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•14 years ago
|
||
Status: NEW → RESOLVED
blocking2.0: --- → ?
Closed: 14 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Assignee | ||
Updated•14 years ago
|
Target Milestone: --- → mozilla2.2
Assignee | ||
Comment 13•14 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•14 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: ? → -
Attachment #523069 -
Flags: approval2.0? → approval2.0-
Comment 15•14 years ago
|
||
Verified fixed with Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0a2) Gecko/20110512 Firefox/5.0a2
Status: RESOLVED → VERIFIED
Updated•14 years ago
|
Updated•14 years ago
|
Alias: CVE-2011-2370
Updated•14 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•