Closed Bug 468581 (CVE-2009-0354) Opened 16 years ago Closed 16 years ago

XSS using a chrome XBL method and window.eval

Categories

(Core :: Security, defect, P1)

Product:
Core
Component:
Security
Platform:
x86
Windows XP
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.9.1b3

People

(Reporter: moz_bug_r_a4, Assigned: mrbkap)

Details

(Keywords: verified1.9.0.6, verified1.9.1, Whiteboard: [sg:high] post 1.8-branch)

Attachments

(1 file)

Fix
953 bytes, patch
brendan
: review+
dveditz
: approval1.9.0.6+
Details | Diff | Splinter Review 
http://mxr.mozilla.org/mozilla-central/source/js/src/jsobj.cpp#1260

1260             if (obj != callerScopeChain) {
1261                 ok = js_CheckPrincipalsAccess(cx, obj,
1262                                               caller->script->principals,
1263                                               cx->runtime->atomState.evalAtom);
1264                 if (!ok)
1265                     goto out;
1266 
1267                 scopeobj = js_NewWithObject(cx, obj, callerScopeChain, -1);

caller->script->principals can be the wrong principal when caller is a cloned
function.  And, when obj_eval is called via XPC_XOW_FunctionWrapper, |obj| is a
window object not wrapped in XOW.  Thus, by using a chrome XBL method and
window.eval, it's possible to access properties of a cross-origin window.

fx2 is not vulnerable since fx2 has the security checks for the window object. 
(By using a chrome XBL method, it's possible to execute eval() with a
cross-origin window, but it's not possible to access properties of the
cross-origin window.)
This is all me. I hate eval.
Assignee: nobody → mrbkap
Flags: blocking1.9.1?
Flags: blocking1.9.0.6?
"high" impact for now, but should we find yet another way to load a chrome-privileged frame this would be rated "critical".
Flags: wanted1.9.0.x+
Flags: wanted1.8.1.x-
Whiteboard: [sg:high] post 1.8-branch
Flags: blocking1.9.0.6? → blocking1.9.0.6+
Attached patch Fix — — Splinter Review 
A while ago, I went through all uses of '>principals' in JS to vet for this. I'm not sure how this slipped through the net.
Attachment #352425 - Flags: review?(brendan)
Attachment #352425 - Flags: review?(brendan)
Attachment #352425 - Flags: review+
Attachment #352425 - Flags: approval1.9.1?
Flags: blocking1.9.1? → blocking1.9.1+
Priority: -- → P1
Target Milestone: --- → mozilla1.9.1b3
Attachment #352425 - Flags: approval1.9.1?
http://hg.mozilla.org/mozilla-central/rev/dcff67f75d7c
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Blake, this still needs to land in 1.9.1, right? And does this patch apply to 1.9.0?
Whiteboard: [sg:high] post 1.8-branch → [sg:high][needs 1.9.1 landing][needs 1.9.0 patch] post 1.8-branch
Comment on attachment 352425 [details] [diff] [review]
Fix

This patch applies to the 1.9.0 branch as-is.
Attachment #352425 - Flags: approval1.9.0.6?
Whiteboard: [sg:high][needs 1.9.1 landing][needs 1.9.0 patch] post 1.8-branch → [sg:high][needs 1.9.1 landing] post 1.8-branch
Comment on attachment 352425 [details] [diff] [review]
Fix

Approved for 1.9.0.6, a=dveditz for release-drivers.
Attachment #352425 - Flags: approval1.9.0.6? → approval1.9.0.6+
Fixed on the 1.9.0 branch.
Keywords: fixed1.9.0.6
not for 1.8.0 branch either.
Flags: wanted1.8.0.x-
Verified fixed for 1.9.0.6 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.6pre) Gecko/2009011304 GranParadiso/3.0.6pre.
Keywords: fixed1.9.0.6 → verified1.9.0.6
Whiteboard: [sg:high][needs 1.9.1 landing] post 1.8-branch → [sg:high] post 1.8-branch
Group: core-security
Alias: CVE-2009-0354
Verified fixed for 1.9.1 with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1pre) Gecko/20090526 Shiretoko/3.5pre.
Keywords: fixed1.9.1 → verified1.9.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: