Closed
Bug 531364
(CVE-2010-0171)
Opened 15 years ago
Closed 15 years ago
Fix for bug 380474 does not work with security wrappers
Categories
(Core :: Security, defect)
Core
Security
Tracking
()
VERIFIED
FIXED
mozilla1.9.3a1
People
(Reporter: moz_bug_r_a4, Assigned: mrbkap)
Details
(Keywords: verified1.9.0.18, verified1.9.1, verified1.9.2, Whiteboard: [sg:high][3.6.x])
Attachments
(6 files, 2 obsolete files)
1.27 KB,
patch
|
peterv
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
906 bytes,
patch
|
peterv
:
review+
bzbarsky
:
superreview+
|
Details | Diff | Splinter Review |
2.38 KB,
patch
|
dveditz
:
approval1.9.2.1+
|
Details | Diff | Splinter Review |
2.67 KB,
patch
|
dveditz
:
approval1.9.1.8+
dveditz
:
approval1.9.0.18+
|
Details | Diff | Splinter Review |
2.16 KB,
patch
|
jst
:
review+
dveditz
:
approval1.9.1.8+
dveditz
:
approval1.9.0.18+
|
Details | Diff | Splinter Review |
2.66 KB,
patch
|
Details | Diff | Splinter Review |
Bug 380474 was fixed by innerizing a window early to force an event listener to
be attached to the old inner window. But, that fix does not deal with security
wrappers (OBJ_TO_INNER_OBJECT(cx, obj) does nothing if obj is a security
wrapper).
And, we need a new fix once a patch in bug 428229 removes
nsEventReceiverSH::AddEventListenerHelper.
On 1.9.1/1.9.0 branches, it's possible to perform an XSS attack. On trunk and
1.9.2 branch, due to the fix for bug 504021, it's not possible to run code with
the privileges of a target site, but e.g. it's possible to sniff keystrokes on
a target site.
Comment 5•15 years ago
|
||
(In reply to comment #0)
> And, we need a new fix once a patch in bug 428229 removes
> nsEventReceiverSH::AddEventListenerHelper.
In a build with the patches for bug 428229 the two testcases from bug 380474 don't work. The "Components.lookupMethod(frames[1].location, "href")" throws, and if I add a line to dump frames[1].location I get "Permission denied for <file://> to call method Location.toString on <http://www.mozilla.com>.".
Reporter | ||
Comment 6•15 years ago
|
||
Yes. In the past, Components.lookupMethod(crossOriginWindow.location, "href")
did not throw, but now it throws because a Location object is wrapped in an
XOW.
In a build with the patches for bug 428229, testcase 3 & 4 in this bug work
(and testcase 1 & 2 can attach event listeners to the target site).
Comment 7•15 years ago
|
||
(In reply to comment #6)
> In a build with the patches for bug 428229, testcase 3 & 4 in this bug work
> (and testcase 1 & 2 can attach event listeners to the target site).
Ok, just to be clear about what you're saying, we'll need a new fix for this bug after the patches for bug 428229 land, but it doesn't regress bug 380474?
Reporter | ||
Comment 8•15 years ago
|
||
What I meant to say is that removing nsEventReceiverSH::AddEventListenerHelper
regresses bug 380474 (the problem fixed in bug 380474 is that an attacker can
attach an event listener to a target site).
Bug 380474 was fixed by innerizing a window in
nsEventReceiverSH::AddEventListenerHelper (and
nsXPCComponents_Utils::LookupMethod), thus if we remove
nsEventReceiverSH::AddEventListenerHelper then we need to innerize a window
somewhere or fix the problem in a different way (e.g. doing security check in
nsGlobalWindow::AddEventListener).
Updated•15 years ago
|
blocking1.9.1: --- → ?
Flags: wanted1.9.0.x?
Whiteboard: [sg:high]
Comment 9•15 years ago
|
||
Nominating for 1.9.2 in the absense of a multistate flag.
blocking1.9.1: ? → needed
status1.9.1:
--- → wanted
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.2?
Whiteboard: [sg:high] → [sg:high][3.6.x]
Comment 11•15 years ago
|
||
For mrbkap. I gave up after we realized we need to audit all callers of XPCNativeWrapper::GetWrappedNative.
Assignee | ||
Comment 12•15 years ago
|
||
As a note: the CheckPropertyAccess calls are now obsolete because nothing can happen between the call to GetJSObjectOfWrapper (which actually does a security check as well as unwraps security wrappers) to change the principal of the passed-in object, but we can keep them for now.
This patch just makes sure that we unwrap sooner, basically.
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #418295 -
Flags: superreview?(bzbarsky)
Attachment #418295 -
Flags: review?(peterv)
Updated•15 years ago
|
Attachment #418295 -
Flags: superreview?(bzbarsky) → superreview+
Comment 13•15 years ago
|
||
Comment on attachment 418295 [details] [diff] [review]
Patch
File a followup on removing the dead code?
Updated•15 years ago
|
Attachment #418295 -
Flags: review?(peterv) → review+
Assignee | ||
Comment 14•15 years ago
|
||
(In reply to comment #13)
> File a followup on removing the dead code?
There isn't much of a point since the code is going away in bug 428229.
Assignee | ||
Comment 15•15 years ago
|
||
Comment on attachment 417954 [details] [diff] [review]
Start of a patch
I filed bug 536480 for pursuing this patch.
Attachment #417954 -
Attachment is obsolete: true
Assignee | ||
Comment 16•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 17•15 years ago
|
||
Comment on attachment 418295 [details] [diff] [review]
Patch
I'm not entirely sure what release to nominate this for, but 1.9.2.1 seems like a decent enough choice.
Attachment #418295 -
Flags: approval1.9.2.1?
Assignee | ||
Comment 18•15 years ago
|
||
The backport was trivial.
Attachment #418939 -
Flags: approval1.9.1.8?
Reporter | ||
Comment 19•15 years ago
|
||
The problem in nsXPCComponents_Utils::LookupMethod is not fixed (the patch in
comment 12 fixes testcase 3 but does not fix testcase 4).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee | ||
Comment 20•15 years ago
|
||
Sorry, I missed that there were two different bugs here, somehow :-/.
Attachment #419048 -
Flags: superreview?(bzbarsky)
Attachment #419048 -
Flags: review?(peterv)
Updated•15 years ago
|
Attachment #419048 -
Flags: superreview?(bzbarsky) → superreview+
Updated•15 years ago
|
Attachment #419048 -
Flags: review?(peterv) → review+
Assignee | ||
Comment 21•15 years ago
|
||
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Comment 22•15 years ago
|
||
Comment on attachment 418939 [details] [diff] [review]
For 1.9.1
Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #418939 -
Flags: approval1.9.1.8? → approval1.9.1.8+
Updated•15 years ago
|
blocking1.9.1: needed → .8+
Updated•15 years ago
|
Whiteboard: [sg:high][3.6.x] → [sg:high][3.6.x][needs 1.9.1 landing]
Comment 23•15 years ago
|
||
Do we need branch approvals or a different branch patch for "Fix for that too" (attachment 419048 [details] [diff] [review])?
Updated•15 years ago
|
blocking1.9.2: --- → ?
Assignee | ||
Updated•15 years ago
|
Attachment #418295 -
Flags: approval1.9.2.1?
Assignee | ||
Comment 24•15 years ago
|
||
Attachment #418939 -
Attachment is obsolete: true
Attachment #422653 -
Flags: approval1.9.2.1?
Assignee | ||
Comment 25•15 years ago
|
||
Attachment #422654 -
Flags: approval1.9.1.8?
Assignee | ||
Comment 26•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/2ce89e85b342 includes both patches. I'll leave the approval request for an ex-post-facto approval.
Updated•15 years ago
|
Attachment #422653 -
Flags: approval1.9.2.1? → approval1.9.2.1+
Assignee | ||
Comment 28•15 years ago
|
||
status1.9.2:
--- → .1-fixed
Assignee | ||
Updated•15 years ago
|
Whiteboard: [sg:high][3.6.x][needs 1.9.1 landing] → [sg:high][3.6.x]
Comment 30•15 years ago
|
||
Comment on attachment 422654 [details] [diff] [review]
For 1.9.1
Approved for 1.9.1.8, a=dveditz for release-drivers
Attachment #422654 -
Flags: approval1.9.1.8? → approval1.9.1.8+
Assignee | ||
Updated•15 years ago
|
Attachment #422654 -
Flags: approval1.9.0.18?
Comment 31•15 years ago
|
||
Comment on attachment 422654 [details] [diff] [review]
For 1.9.1
Approved for 1.9.0.18, a=dveditz
Attachment #422654 -
Flags: approval1.9.0.18? → approval1.9.0.18+
Assignee | ||
Comment 32•15 years ago
|
||
Checking in dom/src/base/nsDOMClassInfo.cpp;
/cvsroot/mozilla/dom/src/base/nsDOMClassInfo.cpp,v <-- nsDOMClassInfo.cpp
new revision: 1.557; previous revision: 1.556
done
Checking in js/src/xpconnect/src/xpccomponents.cpp;
/cvsroot/mozilla/js/src/xpconnect/src/xpccomponents.cpp,v <-- xpccomponents.cpp
new revision: 1.142; previous revision: 1.141
done
Keywords: fixed1.9.0.18
Reporter | ||
Comment 33•15 years ago
|
||
The fix for AddEventListenerHelper in 1.9.1/1.9.0 does not work. After
innerizing obj, wrapper is still the outer window, but we get eventTarget from
wrapper.
http://mxr.mozilla.org/mozilla1.9.1/source/dom/src/base/nsDOMClassInfo.cpp#7245
Comment 34•15 years ago
|
||
Verified fixed with builds on trunk and 1.9.2:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.3a1pre) Gecko/20100126 Minefield/3.7a1pre (.NET CLR 3.5.30729) ID:20100126052630
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.2pre) Gecko/20100127 Namoroka/3.6.2pre (.NET CLR 3.5.30729) ID:20100127045624
(In reply to comment #33)
> The fix for AddEventListenerHelper in 1.9.1/1.9.0 does not work. After
> innerizing obj, wrapper is still the outer window, but we get eventTarget from
> wrapper.
I believe you mean testcase 3? When testing with recent builds of Shiretoko and Gran Paradiso this test fails for me. As result I will remove the fixed flags.
Severity: normal → critical
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.18 → verified1.9.2
Target Milestone: --- → mozilla1.9.3a1
Version: unspecified → Trunk
Updated•15 years ago
|
Flags: in-testsuite?
Comment 35•15 years ago
|
||
At least testcase 3 is still positive for 1.8.0 with applied patch.
Reporter | ||
Comment 36•15 years ago
|
||
1.9.1 patch fixes testcase 2 & 4 but does not fix testcase 1 & 3. The reason
testcase 1 no longer works is that a patch in bug 504021 fixed part of testcase
1 & 2.
Assignee | ||
Comment 37•15 years ago
|
||
Attachment #424159 -
Flags: review?(jst)
Comment 38•15 years ago
|
||
Updated•15 years ago
|
Whiteboard: [sg:high][3.6.x] → [sg:high][3.6.x][needs 1.9.1 r=jst]
Updated•15 years ago
|
Updated•15 years ago
|
Attachment #424159 -
Flags: review?(jst) → review+
Assignee | ||
Updated•15 years ago
|
Attachment #424159 -
Flags: approval1.9.1.8?
Attachment #424159 -
Flags: approval1.9.0.18?
Updated•15 years ago
|
Attachment #424159 -
Flags: approval1.9.1.8?
Attachment #424159 -
Flags: approval1.9.1.8+
Attachment #424159 -
Flags: approval1.9.0.18?
Attachment #424159 -
Flags: approval1.9.0.18+
Comment 39•15 years ago
|
||
Comment on attachment 424159 [details] [diff] [review]
Re-fix that
Approved for 1.9.1.8 and 1.9.0.18, a=dveditz
Updated•15 years ago
|
Whiteboard: [sg:high][3.6.x][needs 1.9.1 r=jst] → [sg:high][3.6.x][needs 1.9.1/1.9.0 landing]
Assignee | ||
Comment 40•15 years ago
|
||
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/d8ca06471009
Checking in dom/src/base/nsDOMClassInfo.cpp;
/cvsroot/mozilla/dom/src/base/nsDOMClassInfo.cpp,v <-- nsDOMClassInfo.cpp
new revision: 1.558; previous revision: 1.557
done
Checking in js/src/xpconnect/src/xpccomponents.cpp;
/cvsroot/mozilla/js/src/xpconnect/src/xpccomponents.cpp,v <-- xpccomponents.cpp
new revision: 1.143; previous revision: 1.142
done
Keywords: fixed1.9.0.18
Whiteboard: [sg:high][3.6.x][needs 1.9.1/1.9.0 landing] → [sg:high][3.6.x]
Updated•15 years ago
|
Attachment #422653 -
Flags: approval1.9.2.2+ → approval1.9.2.1+
Comment 41•15 years ago
|
||
Verified fixed on 1.9.1 with builds on all platforms like Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8) Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729) ID:20100202153512
Comment 42•15 years ago
|
||
Verified for 1.9.0.18 on all platforms as well using attached testcases. All fixed now.
Keywords: fixed1.9.0.18 → verified1.9.0.18
Updated•15 years ago
|
Alias: CVE-2010-0171
Updated•15 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•