Closed Bug 628231 Opened 13 years ago Closed 13 years ago

Arbitrary code execution using history.pushState

Categories

(Core :: Security, defect)

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

Tracking

()

Status:
VERIFIED FIXED
Tracking Flags:
Tracking Status
blocking2.0 --- betaN+
status1.9.2 --- unaffected
status1.9.1 --- unaffected

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Whiteboard: [sg:critical][hardblocker][has patch][fx4-fixed-bugday] )

Attachments

(1 file, 2 obsolete files)

Fixing that too
2.51 KB, patch
Details | Diff | Splinter Review 
When calling history.pushState, nsDocShell::StringifyJSValVariant pushes a JS
context associated with the history object.  Thus, it's possible to call a
native function without a frame or a pushed principal, in which case a result
of nsScriptSecurityManager::IsCapabilityEnabled() is true.

1.9.2/1.9.1 branches do not have history.pushState method.
Attached file testcase — 
This uses bug 344495's trick.
I've heard discussion of issues like this over desk separators in the office, so conceivably this is known and/or a dup -- adding people in or implicated in those discussions to the CC list.
Attached patch Fix (obsolete) — — Splinter Review 
There are better fixes. But they'll have to wait until after Firefox 4 has shipped (namely attaching the context principals stack to the compartment).
Assignee: nobody → mrbkap
Status: NEW → ASSIGNED
Attachment #506939 - Flags: review?(jst)
blocking2.0: --- → betaN+
Whiteboard: [sg:critical][hardblocker]
Attachment #506939 - Flags: review?(jst) → review+
Fix landed:

http://hg.mozilla.org/mozilla-central/rev/244738bdb248
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
This got backed out due to crashes on tbpl. mrbkap has a fix, but we deemed it too dangerous to land this late tonight.

http://hg.mozilla.org/mozilla-central/rev/3eaae2138586
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch Updated fix (obsolete) — — Splinter Review 
The last patch had a dumb mistake in it and would try to do stuff even if we hadn't set obj. This one avoids that mistake.
Attachment #506939 - Attachment is obsolete: true
Attachment #508037 - Flags: review?(jst)
Comment on attachment 508037 [details] [diff] [review]
Updated fix

r=jst, but there's some 2 vs 4 space indentation inconsistencies here. I can fix that when I land this...
Attachment #508037 - Flags: review?(jst) → review+
Attached patch Fixing that too — — Splinter Review 

        Attachment #508037 -
        Attachment is obsolete: true

    
  
Whiteboard: [sg:critical][hardblocker] → [sg:critical][hardblocker][has patch]

    
    

    
  
Updated fix landed.

http://hg.mozilla.org/mozilla-central/rev/5502c6978c73
Status: REOPENED → RESOLVED
Closed: 13 years ago → 13 years ago
Resolution: --- → FIXED

    
    

    
  
Verified bad behavior in Firefox 4 b10 and fix in b11 build (Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:2.0b11) Gecko/20100101 Firefox/4.0b11) using attached testcase.
Status: RESOLVED → VERIFIED
Whiteboard: [sg:critical][hardblocker][has patch] → [sg:critical][hardblocker][has patch][fx4-fixed-bugday]

    
  
Group: core-security → core-security-release
Group: core-security-release

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