Closed
Bug 674182
(CVE-2011-3655)
Opened 14 years ago
Closed 14 years ago
Arbitrary code execution with NoWaiverWrapper/CrossOriginWrapper
Categories
(Core :: Security, defect)
Tracking
()
VERIFIED
FIXED
mozilla8
People
(Reporter: moz_bug_r_a4, Assigned: mrbkap)
References
Details
(Keywords: verified-aurora, verified-beta, Whiteboard: [sg:critical][qa!])
Attachments
(2 files)
293 bytes,
text/html
|
Details | |
1.00 KB,
patch
|
jst
:
review+
|
Details | Diff | Splinter Review |
This is a regression from compartments landing.
The old SJOW used to set aside the frame chain, but the new wrappers don't.
NoWaiverWrapper::enter clamps a principal, but there is a chrome code on the
frame chain, thus a result of nsScriptSecurityManager::IsCapabilityEnabled() is
true.
Firefox 5, 6, 7, and trunk are affected. Firefox 3.6 is not affected.
Reporter | ||
Comment 1•14 years ago
|
||
Assignee | ||
Comment 3•14 years ago
|
||
Does anybody think that we have too many ways of expressing "elevated privileges"? Because I think we have too many ways of expressing that.
Whiteboard: [sg:critical]
Assignee | ||
Comment 4•14 years ago
|
||
This makes nsScriptSecurityManager::IsCapabilityEnabled respect the principals clamping stuff.
Note that this patch is relatively delicate in that we have to respect the clamped frame's principal (and privileges). Also note that there is a slight behavioral change with this patch: before it, if we clamped the same principal onto the stack, this code would have continued searching up the stack frame for principal-enabling stack frames. Now it stops at the clamped frame, resulting in strictly reduced privileges. Given the spots where we clamp principals, I'm not really worried about this change causing regressions.
Assignee | ||
Comment 5•14 years ago
|
||
For what it's worth: jst reviewed this in person yesterday. I'll let him stamp it, but I'm going to land this on inbound before he does.
Assignee | ||
Comment 6•14 years ago
|
||
Whiteboard: [sg:critical] → [sg:critical][inbound]
Updated•14 years ago
|
Attachment #548628 -
Flags: review?(jst) → review+
Comment 7•14 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical][inbound] → [sg:critical]
Target Milestone: --- → mozilla8
Updated•13 years ago
|
status1.9.2:
--- → unaffected
status-firefox10:
--- → fixed
status-firefox7:
--- → wontfix
status-firefox8:
--- → fixed
status-firefox9:
--- → fixed
tracking-firefox10:
--- → +
tracking-firefox7:
--- → -
tracking-firefox8:
--- → +
tracking-firefox9:
--- → +
Updated•13 years ago
|
Alias: CVE-2011-3655
Updated•13 years ago
|
Attachment #548395 -
Attachment is private: true
Updated•13 years ago
|
Attachment #548395 -
Attachment is private: false
Comment 8•13 years ago
|
||
Verified fixed in Firefox 8 with both testcases: Mozilla/5.0 (Windows NT 5.1; rv:8.0) Gecko/20100101 Firefox/8.0
Verified fixed in Firefox 9: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20100101 Firefox/9.0
Verified fixed in Firefox 10: Mozilla/5.0 (Windows NT 5.1; rv:10.0a2) Gecko/20111205 Firefox/10.0a2
Status: RESOLVED → VERIFIED
Keywords: verified-aurora,
verified-beta
Whiteboard: [sg:critical][qa+] → [sg:critical][qa!]
Updated•13 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•