Last Comment Bug 674182 - (CVE-2011-3655) Arbitrary code execution with NoWaiverWrapper/CrossOriginWrapper
(CVE-2011-3655)
: Arbitrary code execution with NoWaiverWrapper/CrossOriginWrapper
Status: VERIFIED FIXED
[sg:critical][qa!]
: verified-aurora, verified-beta
Product: Core
Classification: Components
Component: Security (show other bugs)
: unspecified
: x86 Windows XP
: -- normal (vote)
: mozilla8
Assigned To: Blake Kaplan (:mrbkap) (please use needinfo!)
:
Mentors:
Depends on: 681461
Blocks:
  Show dependency treegraph
 
Reported: 2011-07-26 01:53 PDT by moz_bug_r_a4
Modified: 2012-01-19 11:26 PST (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wontfix
+
fixed
+
fixed
+
fixed
unaffected


Attachments
testcase 1 (293 bytes, text/html)
2011-07-26 01:55 PDT, moz_bug_r_a4
no flags Details
Proposed fix (1.00 KB, patch)
2011-07-26 16:24 PDT, Blake Kaplan (:mrbkap) (please use needinfo!)
jst: review+
Details | Diff | Review

Description moz_bug_r_a4 2011-07-26 01:53:59 PDT
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.
Comment 1 moz_bug_r_a4 2011-07-26 01:55:20 PDT
Created attachment 548395 [details]
testcase 1
Comment 3 Blake Kaplan (:mrbkap) (please use needinfo!) 2011-07-26 15:56:39 PDT
Does anybody think that we have too many ways of expressing "elevated privileges"? Because I think we have too many ways of expressing that.
Comment 4 Blake Kaplan (:mrbkap) (please use needinfo!) 2011-07-26 16:24:38 PDT
Created attachment 548628 [details] [diff] [review]
Proposed fix

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.
Comment 5 Blake Kaplan (:mrbkap) (please use needinfo!) 2011-07-27 12:27:24 PDT
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.
Comment 6 Blake Kaplan (:mrbkap) (please use needinfo!) 2011-07-27 12:53:49 PDT
http://hg.mozilla.org/integration/mozilla-inbound/rev/83535f44db38
Comment 7 :Ehsan Akhgari (out sick) 2011-07-28 08:17:32 PDT
http://hg.mozilla.org/mozilla-central/rev/83535f44db38
Comment 8 [On PTO until 6/29] 2011-12-06 11:44:51 PST
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

Note You need to log in before you can comment on or make changes to this bug.