__proto__ security

Allen Wirfs-Brock allen at wirfs-brock.com
Mon Jan 30 08:30:13 PST 2012

On Jan 30, 2012, at 7:08 AM, Mark S. Miller wrote:

> On Sun, Jan 29, 2012 at 6:25 PM, Allen Wirfs-Brock <allen at wirfs-brock.com> wrote:
> [...]
> I would specify it as a modification to the normal [[Get]] and [[Put]] behavior that special cases on the property key value "__proto__".  That special case (of [[Put]]) would not call  [[DefineOwnPropertry]]. It would include check the prototype chain but that is part of the proposed semantics.
> Then how would you explain the absence of magic after 
>     delete Object.prototype.__proto__;
>     Object.prototype.__proto__ = 8;
> ? After these two lines, it should be a normal data property with value 8. If the original property is an accessor, then this falls out nicely -- the magic is in the setter, which is dispensed with in the first line.

It would simply be part of the special case behavior I would define for [[Get]] and [[Put]].  The disabling effect doesn't require any sort was computational mechanism, a few prose words such as "if the "__proto__" own  property of Object.prototype has been modified in any manner from its initial state described in B.x.y.z..."

> If we do make __proto__ appear to be a data property, I think the right way to do it is to specify (and probably also to implement) it as an accessor, but then to specify magical behavior for [[GetOwnProperty]] that lies -- reporting that it is a data property. However, starting from that assumption, I become increasingly uncomfortable with other implications: When should [[DefineOwnProperty]] maintain the illusion vs simply replace it with the property described by the arguments to [[DefineOwnProperty]]? Perhaps the least surprising would be that any call to [[DefineOwnProperty]] replaces the magic with the property described. But any answer to this question will be surprising in some circumstances.
> This seems like a perfectly reasonable way to specify this.  As __proto__ does indeed affect the property access semantics for every object.   Of course, I'm only talking specification.  How you accomplish it in your implementation is up to you.
> There are other, alternatives.
> If we were willing to only define obj.__proto__ and exclude obj["__proto__"] I could specify it in 11.2.1 as a special case semantics of dot property access notation and have to extend any of the internal methods.
> Again, if you specify it this way, how would you cope with deletion followed by addition? 
as above
> From this discussion, I'm leaning towards Gavin's position. The first element of language design style perhaps should be "Omit Needless Magic". Your five cases you enumerated are not needless. Aside from the toxic waste of non-strict mode, we are left with only three cases, all of which have to do with indexing into the array-like types Array and String. The trouble caused by array length has been quite painful, even though it is non-configurable. The problems I raise above happen when combining magic with configurability, which doesn't have any precedent among strict native objects.

I suggest that you all just focus on the any open issues concerning the actual intended semantics and let me worry about drafting the specification language for it.  Gavin's concern about whether or not __proto__ manifests as a data property is such an issue.  I can handle figuring out a way to best express that decision on the context of our specification.  One it is in the draft you can comment on the actual spec. language.

> The one argument I know for the magic, which initially convinced me, is the tighter intra-frame restriction that results. But this extra tightness is AFAICT not relevant to security, given that __proto__ is limited to its own frame and can be deleted. Are there any other arguments in favor of magic here?

I don't seen any magic...I just we special cases that must be covered in the specification.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20120130/cd0691ad/attachment.html>

More information about the es-discuss mailing list