Closed Bug 674182 (CVE-2011-3655) Opened 13 years ago Closed 13 years ago

Arbitrary code execution with NoWaiverWrapper/CrossOriginWrapper

Categories

(Core :: Security, defect)

Product:
Core
Component:
Security
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla8
Tracking Flags:
Tracking Status
firefox7 - wontfix
firefox8 + fixed
firefox9 + fixed
firefox10 + fixed
status1.9.2 --- unaffected

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

References

Details

(Keywords: verified-aurora, verified-beta, Whiteboard: [sg:critical][qa!])

Attachments

(2 files)

testcase 1
293 bytes, text/html
Details
Proposed fix
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.
Attached file testcase 1 — 

    
    

    
  
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]

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Proposed fix
        — 
          — Splinter Review
      

    


  
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: nobody → mrbkap
Status: NEW → ASSIGNED

        Attachment #548628 -
        Flags: review?(jst)

    
    

    
  
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.

    
    

    
  
http://hg.mozilla.org/integration/mozilla-inbound/rev/83535f44db38
Whiteboard: [sg:critical] → [sg:critical][inbound]

        Attachment #548628 -
        Flags: review?(jst) → review+

    
    

    
  
http://hg.mozilla.org/mozilla-central/rev/83535f44db38
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [sg:critical][inbound] → [sg:critical]
Target Milestone: --- → mozilla8
Alias: CVE-2011-3655

        Attachment #548395 -
        Attachment is private: true

        Attachment #548395 -
        Attachment is private: false

    
  
Whiteboard: [sg:critical] → [sg:critical][qa+]

    
    

    
  
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!]
Group: core-security

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: