Closed
Bug 514435
Opened 16 years ago
Closed 16 years ago
Bypassing XOW by using SJOW
Categories
(Core :: XPConnect, defect, P1)
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)
2.04 KB,
patch
|
jst
:
review+
sicking
:
superreview+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•16 years ago
|
||
This tries to get cookies for www.mozilla.com.
Updated•16 years ago
|
Component: Security → XPConnect
QA Contact: toolkit → xpconnect
Updated•16 years ago
|
Whiteboard: [sg:high]
Updated•16 years ago
|
Assignee: nobody → mrbkap
Flags: blocking1.9.2?
Updated•16 years ago
|
Updated•16 years ago
|
Whiteboard: [sg:high] → [sg:high] probably critical given a privileged context to attack
Updated•16 years ago
|
blocking1.9.1: ? → .4+
Updated•16 years ago
|
Flags: blocking1.9.0.15+
Updated•16 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.2
Updated•16 years ago
|
blocking1.9.1: .4+ → needed
Updated•16 years ago
|
Flags: blocking1.9.0.15+ → blocking1.9.0.16?
Assignee | ||
Comment 2•16 years ago
|
||
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 3•16 years ago
|
||
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+
Assignee | ||
Comment 4•16 years ago
|
||
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 5•16 years ago
|
||
Can this land on mozilla-1.9.2? It blocks the beta of Firefox 3.6 ...
Assignee | ||
Comment 6•16 years ago
|
||
status1.9.2:
--- → beta1-fixed
Updated•16 years ago
|
blocking1.9.1: needed → .5+
Flags: blocking1.9.0.16? → blocking1.9.0.16+
Comment 7•16 years ago
|
||
Blake: We need a port of this for 1.9.1.5 and 1.9.0.16.
Comment 8•16 years ago
|
||
Blake: Where are you on a branch port here? Code freeze is November 10 at 11:59pm.
Comment 9•16 years ago
|
||
Nevermind, I see bug 520522 and bug 524994.
Flags: blocking1.9.0.16+ → blocking1.9.0.17+
Updated•16 years ago
|
blocking1.9.1: .6+ → .7+
Comment 10•16 years ago
|
||
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?
Updated•16 years ago
|
blocking1.9.1: .8+ → .9+
Flags: blocking1.9.0.18+ → blocking1.9.0.19+
Comment 11•15 years ago
|
||
Please to be answering comment 10!
Assignee | ||
Comment 12•15 years ago
|
||
Once the blocking bugs land on trunk (hopefully tomorrow), I'll be able to backport them to older branches.
Comment 13•15 years ago
|
||
Have they landed? Where are we on this?
Updated•15 years ago
|
blocking1.9.1: .9+ → needed
Flags: blocking1.9.0.19+ → blocking1.9.0.19-
Updated•14 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•