On __proto__ as a magical data property

David Bruant bruant.d at gmail.com
Wed Jul 18 03:35:19 PDT 2012


Le 18/07/2012 11:35, Andreas Rossberg a écrit :
> On 18 July 2012 09:59, David Bruant <bruant.d at gmail.com 
> <mailto:bruant.d at gmail.com>> wrote:
>
>     Im my humble opinion, making Object.prototype.__proto__
>     configurable (and actually deletable) [1] should be a much highier
>     priority than choosing from data to accessor property.
>     As long as Object.prototype.__proto__ is not deletable, a data or
>     accessor property does not matter from a security perspective,
>     it's equally terrible.
>     From the security perspective, it all boils down to whoever runs
>     first. If the attacker runs first, it makes
>     Object.prototype.__proto__ non-configurable and the defender is
>     likely screwed. If the defender runs first, it can "delete
>     Object.prototype.__proto__" and the attacker cannot use __proto__
>     in a nocive manner any longer.
>     If Object.prototype.__proto__ is effectively deletable, data or
>     accessor, the difference is that if you run first and __proto__ is
>     an accessor, you can decide to extract the setter and use it for
>     your own good if you have legitimate use cases. Never sharing this
>     capability will keep you safe.
>
>
> I agree with that. I'm not quite convinced that there are relevant 
> security implication with an accessor semantics either.
What was raised at the previous TC39 meeting (from the notes) was a 
potential security issue when an attacker would change the prototype of 
"host objects" in a way that the implementor didn't really think of, 
increasing the attack surface. I have no experience in implementing a 
web browser, so I won't contradict this point.
For sure, ocap-style design would prevent any issue related to __proto__ 
as a setter, but web browsers are written in C++ and it's unpractical to 
ask to redesign a web browser.
I'm following the bug on the Firefox new DOM bindings and it seems like 
a huge amount of work from where I stand. I can only imagine it's 
equivalently hard for other web browsers.

> I also don't think that array length counts as proper precedence. 
> Array length is a magic property _on the instance_, whose magic is 
> limited to that specific instance, whereas __proto__ would be a magic 
> property _on the prototype_, thereby introducing _cross-object_ magic. 
> I'd argue that's quite a different quality. Do we have any precedence 
> for that?
>
> It simply seems entirely incoherent to me that a single _data_ 
> property should exhibit different values when accessed through 
> different receivers. From my perspective, that's a significantly more 
> fundamental violation of the JS object model than the magic that comes 
> with array length.
Proxies are an even more fundamental violation of the JS object model. 
With proxies, data properties will be able to behave almost arbitrarily 
differently than what we knew before proxies. Actually, with the 
getPrototype trap, __proto__ could be implemented in JS (for individual 
objects).
I don't remember when (likely around April/May 2011), but we had long 
discussions about which invariants proxies should enforce. Conclusions 
are at 
http://wiki.ecmascript.org/doku.php?id=harmony:direct_proxies#invariant_enforcement
In a nutshell, if you do Object.preventExtensions on an object, you can 
rely on things. Likewise if you seal or freeze a property (see 
definition in the page) you have some guaranteed invariants.
All the rest of behaviors you used to rely on for data property is 
broken. The justification is that you need to break these invariants if 
you want to implement the array length example and NodeList numerical 
properties (both being reflected as data properties)

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120718/5f611c4f/attachment.html>


More information about the es-discuss mailing list