Closed Bug 514435 Opened 13 years ago Closed 13 years ago

Bypassing XOW by using SJOW


(Core :: XPConnect, defect, P1)

Windows XP



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


(Reporter: moz_bug_r_a4, Assigned: mrbkap)


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


(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
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]

- 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?

Attachment #403541 - Flags: review?(jst) → review+
Attachment #403541 - Flags: superreview?(jonas) → superreview+
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 and
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.