Closed
Bug 593602
Opened 14 years ago
Closed 14 years ago
Problem with Location object's principal
Categories
(Core :: Security, defect)
Tracking
()
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
blocking2.0 | --- | betaN+ |
status1.9.2 | --- | unaffected |
status1.9.1 | --- | unaffected |
People
(Reporter: moz_bug_r_a4, Assigned: mrbkap)
Details
(Keywords: regression, testcase, Whiteboard: [sg:moderate] leaks site cross-site location, maybe ID's in the URL? fixed-in-tracemonkey)
Attachments
(1 file)
(deleted),
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
This is trunk-only. Regression range: http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2010-08-20+07&enddate=2010-08-21+04 1. Get a Location object of a window. 2. Load a new document in that window. The Location object's principal is still the old document's principal. Thus, it's possible to get a cross-origin window's location.href. When a new document is loaded, the Location object's XPCWrappedNative's XPCWrappedNativeScope does not change, and the XPCWrappedNativeScope's mScriptObjectPrincipal is the old inner window. Thus nsXPConnect::GetPrincipal returns the old inner window's principal with the following assertion failure: ###!!! ASSERTION: Principal mismatch. Not good: '!aAllowShortCircuit || result == doGetObjectPrincipal(origObj, PR_FALSE)', file /home/.../mozilla/caps/src/nsScriptSecurityManager.cpp, line 2470
Reporter | ||
Comment 1•14 years ago
|
||
Comment 2•14 years ago
|
||
There was an 85-changeset tracemonkey merge in that range--including several wrapper fixes from Blake--that's probably the culprit. Need to bisect on the tracemonkey branch to see if we can find the specific bug (so we can track regressions should we ever land whatever it was on stable branches).
Keywords: regression,
regressionwindow-wanted
Whiteboard: [sg:high] leaks site cross-site location
Updated•14 years ago
|
Assignee: nobody → mrbkap
Updated•14 years ago
|
blocking2.0: ? → betaN+
Updated•14 years ago
|
Whiteboard: [sg:high] leaks site cross-site location → [sg:moderate] leaks site cross-site location, maybe ID's in the URL?
Comment 5•14 years ago
|
||
bug 576616 was externally reported and fixed in the upcoming Firefox 3.6.11 and 3.5.14 releases. We really should release an advisory for the fix, but that leaves Firefox 4 beta users somewhat at risk. This should get fixed in beta8, don't wait for final. If this seems like a bad plan we can maybe think about a retro-active advisory, but we really hate doing that unless there's the potential for massive pwnage.
Assignee | ||
Comment 6•14 years ago
|
||
We've already done the "is same origin" check by the time we get into this function. Note that this patch ignores document.domain for location objects. I'll file a separate bug on that.
Attachment #483609 -
Flags: review?(gal)
Updated•14 years ago
|
Attachment #483609 -
Flags: review?(gal) → review+
Assignee | ||
Comment 7•14 years ago
|
||
http://hg.mozilla.org/tracemonkey/rev/b8fd0155fcd2
Whiteboard: [sg:moderate] leaks site cross-site location, maybe ID's in the URL? → [sg:moderate] leaks site cross-site location, maybe ID's in the URL? fixed-in-tracemonkey
Comment 8•14 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/1017ba524465
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Updated•14 years ago
|
status1.9.1:
--- → unaffected
status1.9.2:
--- → unaffected
Updated•12 years ago
|
Attachment #472168 -
Attachment is private: true
Updated•12 years ago
|
Group: core-security
Comment 9•10 years ago
|
||
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: regressionwindow-wanted
You need to log in
before you can comment on or make changes to this bug.
Description
•