Closed Bug 514435 Opened 13 years ago Closed 13 years ago

Bypassing XOW by using SJOW

Categories

(Core :: XPConnect, defect, P1)

x86
Windows XP
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.2
Tracking Status
status1.9.2 --- beta1-fixed
blocking1.9.1 --- needed
status1.9.1 --- wanted

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Whiteboard: [sg:high] probably critical given a privileged context to attack)

Attachments

(1 file)

When SJOW code wraps a same-origin XOW, it unwraps the XOW.  And, when SJOW
code calls an untrusted function, it unwraps arguments that are SJOWs.  Thus,
it's possible to bypass XOW.
Attached file testcase
This tries to get cookies for www.mozilla.com.
Component: Security → XPConnect
QA Contact: toolkit → xpconnect
Whiteboard: [sg:high]
Assignee: nobody → mrbkap
Flags: blocking1.9.2?
blocking1.9.1: --- → ?
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x-
Whiteboard: [sg:high] → [sg:high] probably critical given a privileged context to attack
blocking1.9.1: ? → .4+
Flags: blocking1.9.0.15+
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.2
blocking1.9.1: .4+ → needed
Flags: blocking1.9.0.15+ → blocking1.9.0.16?
Attached patch FixSplinter Review
This fixes the bug by not unwrapping XOWs when wrapping in a SJOW. I also had to fix enumeration in that case because we end up walking the wrong prototype chain to find prototype properties of the XOW (the XOW doesn't even have a prototype at all).
Attachment #403541 - Flags: superreview?(jonas)
Attachment #403541 - Flags: review?(jst)
Comment on attachment 403541 [details] [diff] [review]
Fix

- In XPC_SJOW_Iterator():

+  JSObject *tmp = XPCWrapper::UnwrapGeneric(cx, &sXPC_XOW_JSClass, unsafeObj);
+  if (tmp) {
+    unsafeObj = tmp;

Maybe only do this assignment if we pass the following if check?

r=jst
Attachment #403541 - Flags: review?(jst) → review+
Attachment #403541 - Flags: superreview?(jonas) → superreview+
http://hg.mozilla.org/mozilla-central/rev/70475458eabb
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Can this land on mozilla-1.9.2? It blocks the beta of Firefox 3.6 ...
blocking1.9.1: needed → .5+
Flags: blocking1.9.0.16? → blocking1.9.0.16+
Blake: We need a port of this for 1.9.1.5 and 1.9.0.16.
Blake: Where are you on a branch port here? Code freeze is November 10 at 11:59pm.
Nevermind, I see bug 520522 and bug 524994.
Flags: blocking1.9.0.16+ → blocking1.9.0.17+
blocking1.9.1: .6+ → .7+
What's the status of this and the other two related bugs? I see this one's got sr, one needs a patch and one needs review. They all need to land together, right?
blocking1.9.1: .8+ → .9+
Flags: blocking1.9.0.18+ → blocking1.9.0.19+
Once the blocking bugs land on trunk (hopefully tomorrow), I'll be able to backport them to older branches.
Have they landed? Where are we on this?
blocking1.9.1: .9+ → needed
Flags: blocking1.9.0.19+ → blocking1.9.0.19-
Group: core-security
You need to log in before you can comment on or make changes to this bug.