Why we need to clean up __proto__

Mark S. Miller erights at google.com
Wed Dec 28 18:03:33 PST 2011


Btw, test_JSON_PARSE_PROTO_CONFUSION(), currently at <
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/repairES5.js#1373>,
is how SES's initialization tests for this problem. We do indeed consider
this bug a security hazard, so on those platforms that suffer from this
bug, we repair it using repair_JSON_PARSE_PROTO_CONFUSION(), currently at <
http://code.google.com/p/es-lab/source/browse/trunk/src/ses/repairES5.js#2195
>.


On Wed, Dec 28, 2011 at 3:37 PM, Allen Wirfs-Brock <allen at wirfs-brock.com>wrote:

>
> On Dec 28, 2011, at 11:58 AM, gaz Heyes wrote:
>
> > I'd also like to add that __proto__ allows valid JSON to change it's
> object type and allow functions within properties. There isn't a compelling
> exploit scenerio for this yet but who knows what is possible if setters
> come into the equation.
>
> I assume by "valid JSON" you really mean any object literal rather than
> the use of the built-in JSON.parse function.
>
> The ES5.1 specification for JSON.parse, if strictly followed, should not
> set the the [[Prototype]] of the object created by
> JSON.parse('{"__proto__": []}') to anything other than Object.prototype.
>  The JSON.parse spec. explicitly says  that [[DefineOwnProperty]] is used
> to create for create properties.  The spec. for JSON.parse also says "It is
> not permitted for a conforming implementation of JSON.parse to extend the
> JSON grammars".  It is probably debatable whether or not giving "__proto__"
> special meaning would is iimplicitly a grammar change.  However, the intent
> of that statement was that JSON.parse should must operate as specified and
> without extension.
>
> Firefox (9 at least) appears to conform to the JSON.parse spec. in this
> regard.
>
> TC39 has already agreed that as in ES.next is would provide a a normative
> specification for an "optional" __proto__ feature.  This is a good reminder
> that when we do that we need to carefully specify details such as requiring
> that JSON.parse does not recognize it.
>
> >
> > alert(({"__proto__":[]}).sort)
> > alert(({"__proto__":function::['parent']}).location)
>
> The second example threw me for a while until I figured out that :: is an
> e4X construct.  A conforming implementation of JSON.parse should reject
> such syntax.
>
> Allen




-- 
    Cheers,
    --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20111228/d98ace00/attachment.html>


More information about the es-discuss mailing list