Recap of recent progress

[natevw]

Okay, so here's how I understand #15 works mostly for @kumavis but also adding some followup items I want to check.

According to ES5, even a literal Function Definition follows the algorithm for Creating Function Objects. This algorithm sets the prototype of the new object to "the standard built-in Function prototype object".

This is why I gave up before, but your trick is that as section 15.3 of the spec describes, this "standard built-in" object can still be configured like any other.

The heart of the matter is this line of code:

_gObj.Function.prototype.constructor = evel.Function;

[Note that I’ve simplified it! You were assigning _gObj.Function.constructor.prototype.constructor which is equivalent to _gObj.Function.prototype.constructor.prototype.constructor (since Function.hasOwnProperty('constructor') === false). But Function.prototype.constructor === Function already, which is where the simplified version above comes from.]

So anyway, the way the environment starts out is with (to use V8’s naming) Function.prototype = function Empty() {}. ES5 simply specifies that Function.prototype is a function that accepts any arguments and returns undefined. To quote 15.3.4.1 verbatim: "The initial value of Function.prototype.constructor is the built-in Function constructor." This is what gave us the #12 exploit.

So, the only magic we really have to do is change the constructor value from the initial Function to evel.Function. Assigning _gObj.Function is just taking care of the more obvious access.

We need to assign evel.Function.constructor = evel.Function while setting up the iframe because we have fixed up the iframe context’s Function.prototype.constructor whereas evel.Function still has its original "standard built-in Function" proto from when generated on the main window. (This confused me for a bit: the constructor assignment to self in step 17 of 13.2 happens on the Function.prototype object not the Function.__proto__/Object.getPrototypeOf(Function) one.)

So I think this just might work (great job @kumavis) but I also think there may be some loose ends lying around:

• I suspect setting evel.Function.constructor simply shadows the original Object.getPrototypeOf(evel.Function).constructor and so this needs a more robust work.
• similar for evel, we may need to clean up its chain better too (but c.f. discussion on Cannot evel multiple lines of code #12)
• investigate: will the browser discrepancies noted in http://stackoverflow.com/questions/383172/correct-prototype-chain-for-function cause us any grief?

[natevw]

Yup, confirmed Function.__proto__.constructor("return this")() still gives "[Object Window]"

[natevw]

Looking through the browser discrepancies in the last item, I'm not seeing anything really interesting. There's a thread discussing some of the issues as well: https://mail.mozilla.org/pipermail/es5-discuss/2009-May/002543.html

So there certainly could be something we're still missing, but I think I'm going to close this and simply reiterate the challenge again :-)