Jan 18 meeting notes

David Bruant bruant.d at gmail.com
Fri Jan 20 02:00:47 PST 2012

Le 20/01/2012 00:57, Brendan Eich a écrit :
>> David Bruant <mailto:bruant.d at gmail.com>
>> January 19, 2012 1:43 AM
>> Every time I've been thinking of an issue like this, the solution 
>> I've found was "whoever runs first wins".
> This is not relevant to the example I showed.
All in all, regardless of data or accessor, or the guarantee you put in 
which object can or cannot have its prototype changed, it seems that at 
the very least, security relies (at least partly) on __proto__ being 
deletable (configurable). And deleting it is something that the first 
code that runs gets to decide. If it's trusted code, it can delete it, 
if it's an attacker, it can make it non-configurable.

> We have a de-facto standard with SpiderMonkey
I'm not sure I agree with the idea of a "de-facto standard with 
In Chrome (V8):
var o = Object.create(null);
console.log(o.a); // undefined
o.__proto__ = {a:1};
console.log(o.a); // 1
If something is de-facto, it's SpiderMonkey implementation, not a standard.
And as I showed in an earlier message, there is out there code running 
in node.js (V8) using __proto__, hence making V8's version also worth 
not breaking.

> that protects an object from having its [[Prototype]] changed once it 
> has cut itself off from Object.prototype. Reflecting __proto__ as an 
> accessor breaks this guarantee.

In the strawman [1], the security of an object is not bound to what is 
or is not in the prototype chain, but rather whether or not the object 
is extensible or not. Why wouldn't that be enough?

> Does this matter? Clearly, it does cross-frame in the web embedding
I'm not sure I understand. Can you provide an example please?
Specifically, an example that would show a threat for the accessor 
property case, but not the data property case.

Regarding cross-frame issues, I can't think of how one case is worse 
than the other. Data or accessor, a new frame defines a new Object, a 
new Object.prototype and a new Object.prototype.__proto__. This one has 
to be deleted by the parent.
If in the parent, trusted code run first, it can make sure to be the 
only entity allowed to dynamically create frames and to be the first to 
access them (to delete Object.prototype.__proto__). If in the parent, an 
attacker runs first, it can make sure to be the first one to access the 
frame.Object.prototype and do whatever it wants to its __proto__ property.


[1] http://wiki.ecmascript.org/doku.php?id=strawman:magic_proto_property

More information about the es-discuss mailing list