Closed Bug 593602 Opened 14 years ago Closed 14 years ago

Problem with Location object's principal

Categories

(Core :: Security, defect)

x86
Windows XP
defect
Not set
normal

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)

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
Attached file testcase
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).
Whiteboard: [sg:high] leaks site cross-site location
CC'ing sirdarckat from bug 576616 so he can see his bug get re-fixed.
Keywords: testcase
This seems like it needs to block....
blocking2.0: --- → ?
Assignee: nobody → mrbkap
blocking2.0: ? → betaN+
Whiteboard: [sg:high] leaks site cross-site location → [sg:moderate] leaks site cross-site location, maybe ID's in the URL?
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.
Attached patch FixSplinter Review
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)
Attachment #483609 - Flags: review?(gal) → review+
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
http://hg.mozilla.org/mozilla-central/rev/1017ba524465
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Group: core-security
Issue is resolved - clearing old keywords - qa-wanted clean-up
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: