Beginning on October 25th, 2016, Persona will no longer be an option for authentication on BMO. For more details see Persona Deprecated.
Last Comment Bug 311025 - chrome XBL exposes privileged Function constructor
: chrome XBL exposes privileged Function constructor
[sg:critical] privilege escalation [p...
: js1.6, verified1.7.13, verified1.8
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: All All
: P1 critical (vote)
: mozilla1.8rc1
Assigned To: Blake Kaplan (:mrbkap)
: Jason Orendorff [:jorendorff]
Depends on:
Blocks: sbb?
  Show dependency treegraph
Reported: 2005-10-04 01:19 PDT by shutdown
Modified: 2006-11-10 12:21 PST (History)
11 users (show)
dveditz: blocking1.7.13+
dveditz: blocking‑aviary1.0.8+
asa: blocking1.8b5-
mscott: blocking1.8rc1+
bob: in‑testsuite+
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---

testcase (1.09 KB, text/html)
2005-10-04 01:20 PDT, shutdown
no flags Details
proposed fix (3.63 KB, patch)
2005-10-04 16:31 PDT, Brendan Eich [:brendan]
no flags Details | Diff | Splinter Review
fixed fix (3.64 KB, patch)
2005-10-05 12:49 PDT, Brendan Eich [:brendan]
mrbkap: review+
shaver: superreview+
asa: approval1.8rc1+
Details | Diff | Splinter Review
possible port (3.61 KB, patch)
2005-10-13 01:15 PDT, Blake Kaplan (:mrbkap)
brendan: review-
Details | Diff | Splinter Review
rolled-up patch (9.74 KB, patch)
2005-10-14 16:15 PDT, Blake Kaplan (:mrbkap)
brendan: review+
dveditz: approval‑aviary1.0.8+
dveditz: approval1.7.13+
brendan: approval1.8rc1+
Details | Diff | Splinter Review
test.*.com/tests/ (2.05 KB, text/html)
2005-12-26 17:28 PST, Bob Clary [:bc:]
no flags Details
Backported roll-up patch (7.42 KB, patch)
2006-02-09 14:53 PST, Blake Kaplan (:mrbkap)
brendan: review+
Details | Diff | Splinter Review

Description shutdown 2005-10-04 01:19:31 PDT
You can retrieve the Function constructor from XBL compilation scope by:, "Function")
Retrieved constructor can be used to execute arbitrary code with
elevated privileges if xblMethod is defined in the chrome XBL file.
Comment 1 shutdown 2005-10-04 01:20:41 PDT
Created attachment 198426 [details]

Works on:
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.12) Gecko/20051003 Firefox/1.0.7
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051003 Firefox/1.6a1
Comment 2 Brendan Eich [:brendan] 2005-10-04 16:31:11 PDT
Created attachment 198522 [details] [diff] [review]
proposed fix

The indirectCall case requires another subsumes test, to check whether the
scriped caller of indirect-eval should have access to the scope object
parameter, which in this bug's testcase comes from call or apply walking up
eval's scope chain to the chrome compilation global object for the XBL.

Comment 3 Blake Kaplan (:mrbkap) 2005-10-04 16:35:46 PDT
Comment on attachment 198522 [details] [diff] [review]
proposed fix

Comment 4 moz_bug_r_a4 2005-10-05 01:15:34 PDT
(In reply to comment #2)
I've applied the proposed patch and tested.

That prevents this:
  var fctor =, "Function");

But, that does not prevent this:
  var fctor =, "Function", bound.stop.eval);

@@ -1172,26 +1199,19 @@ obj_eval(JSContext *cx, JSObject *obj, u

-        }
+        ok = CheckEvalAccess(cx, obj, principals);
+        if (!ok)
+            goto out;

Shouldn't this code be the following?

        ok = CheckEvalAccess(cx, scopeobj, principals);
Comment 5 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-10-05 07:52:51 PDT
Comment on attachment 198522 [details] [diff] [review]
proposed fix

Comment 6 Asa Dotzler [:asa] 2005-10-05 11:25:21 PDT
moving out to RC1.
Comment 7 Blake Kaplan (:mrbkap) 2005-10-05 11:31:29 PDT
(In reply to comment #4)
> Shouldn't this code be the following?
>         ok = CheckEvalAccess(cx, scopeobj, principals);

Yes it should, duh. I thought I'd checked that when I reviewed, but apparently I
missed it :-(.

When I make that change locally, your second testcase is also (correctly) blocked.
Comment 8 Brendan Eich [:brendan] 2005-10-05 12:48:18 PDT
Comment on attachment 198522 [details] [diff] [review]
proposed fix

Oh for pete's sake!  Copy paste bug.  Sorry, new patch with scopeobj, not obj,
in second call to CheckEvalAccess in a trice.

Comment 9 Brendan Eich [:brendan] 2005-10-05 12:49:34 PDT
Created attachment 198616 [details] [diff] [review]
fixed fix
Comment 10 Blake Kaplan (:mrbkap) 2005-10-05 13:18:04 PDT
Comment on attachment 198616 [details] [diff] [review]
fixed fix

Yeah, sorry I missed this the first time around.
Comment 11 Mike Shaver (:shaver -- probably not reading bugmail closely) 2005-10-05 21:47:30 PDT
Comment on attachment 198616 [details] [diff] [review]
fixed fix

ulp! sr=shaver

(I am so bad at vacation)
Comment 12 Blake Kaplan (:mrbkap) 2005-10-06 18:44:50 PDT
Fix checked in on trunk. I'm leaving this bug open to explore whether |new
Script| neeeds equal treatment here.
Comment 13 Brendan Eich [:brendan] 2005-10-11 17:57:24 PDT

Comment 14 Blake Kaplan (:mrbkap) 2005-10-13 01:15:06 PDT
Created attachment 199395 [details] [diff] [review]
possible port

I think this is a straightforward eval -> Script fix.
Comment 15 Brendan Eich [:brendan] 2005-10-13 19:14:56 PDT
Comment on attachment 199395 [details] [diff] [review]
possible port

> static JSBool
>+CheckScriptAccess(JSContext *cx, JSObject *scopeobj, JSPrincipals *principals,
>+                  const char *name)

Subroutine the CheckEvalAccess code in jsobj.c, maybe keeping its name and just
prepending js_.

>     if (!scopeobj) {
>         /* No scope object passed in: try to use the caller's scope chain. */
>         if (caller) {
>             /*
>              * Load caller->scopeChain after the conditional js_GetCallObject
>              * call above, which resets scopeChain as well as varobj.
>              */
>             scopeobj = caller->scopeChain;
>+            if (!CheckScriptAccess(cx, obj, caller->script->principals,

obj is wrong here, don't you mean scopeobj?  If you do mean scopeobj, then
there's no point testing whether caller->script->principals subsumes
caller->scopeChain's object principals, since that must be the case (we could
assert it, but not here -- probably where we set up a frame -- and it would
slow down DEBUG builds mightily, so do it only if DEBUG_iamslow).

>+                                   "Script.prototype.compile")) {

"....exec", and common in a static const char [].

Not sure we need this patch either -- figure out whether you meant obj above,
or scopeobj.

The consolidation via js_CheckEvalAccess would be cool, I think.

Comment 16 Blake Kaplan (:mrbkap) 2005-10-14 14:26:48 PDT
Actually, I don't think that Script needs this patch (shutdown and moz_bug_r_a4
should speak up now if I'm wrong!). Marking this bug as fixed on the trunk. I'm
working on landing these patches on the branch.
Comment 17 Blake Kaplan (:mrbkap) 2005-10-14 16:15:48 PDT
Created attachment 199611 [details] [diff] [review]
rolled-up patch

This patch is the best-of all of the security fixes that have gone in lately.
It should make eval and script unassailable (until proven differently, of
Comment 18 Brendan Eich [:brendan] 2005-10-14 17:13:34 PDT
Comment on attachment 199611 [details] [diff] [review]
rolled-up patch

Good to sync with trunk.  Followup patch to consolidate OBJ_INNER_OBJECT into
js_CheckScopeChainValidity TBD.

Comment 19 Blake Kaplan (:mrbkap) 2005-10-14 17:59:13 PDT
Fix checked into MOZILLA_1_8_BRANCH.
Comment 20 Ben Bucksch (:BenB) 2005-10-21 09:03:29 PDT
Which bugs does the "rolled-up patch" fix apart from this one?
I assume nobody is porting this to 1.7 (gives more failures than applied hunks)?
Comment 21 Bob Clary [:bc:] 2005-11-09 15:08:45 PST
tested attachment 198426 [details] in firefox 1.5 rc2 winxp/linux:

Error: function eval must be called directly, and not by way of a function of another name
Source File:
Line: 22
Comment 22 Bob Clary [:bc:] 2005-12-26 17:28:19 PST
Created attachment 206879 [details]
Comment 23 Daniel Veditz [:dveditz] 2006-02-06 12:22:43 PST
Comment on attachment 199611 [details] [diff] [review]
rolled-up patch

aviary101/moz17 landing approval: a=dveditz for drivers. Please add the fixed1.7.13 and fixed-aviary1.0.8 keywords when landed.
Comment 24 Blake Kaplan (:mrbkap) 2006-02-09 14:53:31 PST
Created attachment 211315 [details] [diff] [review]
Backported roll-up patch
Comment 25 Brendan Eich [:brendan] 2006-02-09 15:12:38 PST
Comment on attachment 211315 [details] [diff] [review]
Backported roll-up patch

Sure, bring on part deux!

Comment 26 Daniel Veditz [:dveditz] 2006-02-09 17:31:08 PST
Blake checked in the backported patch to the aviary101/moz17 branches earlier today
Comment 27 Tracy Walker [:tracy] 2006-02-15 12:07:21 PST
verified with:
Moz - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060214
Fx - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.13) Gecko/20060215
Moz - Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.7.13)
Gecko/20060215 Firefox/1.0.8
Fx - Mozilla/5.0 (Macintosh; U;PPC Mac OS X Mach-O; en-US; rv:1.7.13)
Gecko/20060215 Firefox/1.0.8
Moz - Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.7.13) Gecko/20060215

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