__proto__ security

Brendan Eich brendan at mozilla.org
Sat Jan 28 09:16:39 PST 2012


I don't think we should change __proto__ unnecessarily from current 
implementations, including making it an accessor. Neither JSC nor 
SpiderMonkey does that.

We do need the ability to delete it, so it should live on 
Object.prototype and be configurable.

Ignoring the "don't gild the lily" (or "don't polish the turd") advice 
above, if we *do* reflect __proto__ as an accessor, then the same-frame 
problem still exists. Perhaps it can be solved by proxies, but why 
require that?

/be

> Gavin Barraclough <mailto:barraclough at apple.com>
> January 28, 2012 1:02 AM
>
> Hi David,
>
> It seems that the best way to neutralize the thread from new __proto__ 
> instances, would be to simply prohibit __proto__ taken from one iframe 
> to be applied to objects created in another. I think this should be 
> achievable with the following tweaks to the strawman:
>
> * The [[ProtoSetter]] method holds a private reference 
> [[OwnerObjectPrototype]] to the ObjectPrototype upon which .
> * Add a step 2b to the definition of [[ProtoSetter]](Parent), specifying:
> Walk the prototype chain of O, comparing each successive prototype to 
> the stored [[OwnerObjectPrototype]]. If the prototype chain does not 
> contain [[OwnerObjectPrototype]], throw a TypeError.
>
> What do you think? – are there holes this leaves open?
>
> cheers,
> G.
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
> David Bruant <mailto:bruant.d at gmail.com>
> January 20, 2012 4:07 PM
> Hi,
>
> This is an attempt to list and discuss how threats of a mutable
> __proto__ can be prevented and how it is different in the data and
> accessor property cases.
>
> ## One frame
>
> Assuming code from 2 parties are running in the same "frame" (one set of
> built-ins)
>
> -----
> var o = Object.create(Object.freeze({a:1}));
> o.a = 1; // and may assume it will keep being this way unless 
> shadowing 'a'
>
> // passing o to malicious code:
> o.__proto__ = {a:2};
>
> // back in normal code:
> o.a; // 2. hey! WTF!
> -----
>
> ### How to prevent this?
> #### delete Object.prototype.__proto__
>
> Unconditionnally prevents using __proto__ (setting and getting!) for
> everyone (even those who would have "legitimate" use cases).
>
> In case the property is a configurable accessor, the prototype setting
> capability can be removed, getting can be left and the property can be
> made non-configurable. The party who does this can keep the prototype
> setting capability to herself and share with whoever she trusts. It is
> also possible to share an attenuated version of the capability (allowing
> to change the prototype of some objects and not some others)
>
>
> #### non-extensible as protection
>
> Object.preventExtensions(o) would protect just o.
> This technique and the previous one could be used together.
>
>
> ## Several Object.prototype.__proto__ in the same "Vat" (synchronous
> access to several Object.prototype.__proto__)
>
> ### Startup
>
> If there are several Object.prototype at startup, the work to secure all
> of them is just the work to secure one (delete or finer-grained version
> of the accessor case), but repeated.
>
> ### Dynamic creation of Object.prototype.__proto__ instances
>
> If a new Object.prototype.__proto__ becomes reachable (by opening a
> same-origin iframe, for instance), if the parent can run before any
> script in the child, she can do whatever she wants:
> - deleting childframe.Object.prototype.__proto__ if she wants to defend
> against what the child could do
> - redefine any built-ins to attack the child.
> If the child can run some code before the parent is notified that a new
> Object.prototype.__proto__ is reachable, she can protect herself against
> the parent or attack (redefine any built-in) of her parent.
>
> ## Questions
>
> * What are all the cases in nowadays browsers where a new
> Object.prototype.__proto__ can be dynamically created? (The only one I
> can think of is same-domain iframe, but I think there exists some weird
> rules for one frame to access another by changing its own domain to a
> subdomain, or something like this)
> * For each case, who has access to the other first? The creater or the
> creature?
> * One difference that is made in the accessor case is that if one party
> runs before the other, then this first one can keep a reference to the
> setter. Does this increase the already existing attack surface?
>
> David
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>


More information about the es-discuss mailing list