Another de-facto insecurity we need to fix in ES5

Mark S. Miller erights at google.com
Wed Jun 17 19:34:57 PDT 2009


On Wed, Jun 17, 2009 at 7:10 PM, Maciej Stachowiak <mjs at apple.com> wrote:

>
> On Jun 17, 2009, at 3:34 PM, Mark S. Miller wrote:
>
>
>> I suspect we'll see some de-facto stuff come out of one or two vendors who
>> aren't active in TC39 (Apple, Google V8).
>>
>>
>> Google is quite active in TC39. Google's representatives to TC39
>> (including me) are now in close coordination with our v8 team. However, v8
>> remains committed to following WebKit. Fortunately, AFAIK, WebKit has not
>> yet taken any stance on whether [[Prototype]] will be mutable in their ES5
>> implementation. Maciej?
>>
>
> Your phrasing of the question strikes me as odd, because changing behavior
> of de facto extensions like this seems orthogonal to supporting a new
> version of the spec. If getting rid of or restricting mutable __proto__
> turns out to be feasible and a good idea, then we would not tie it to
> implementation timeline for ES5 features.
>

The tie to ES5 is that ES5 introduces the notion of frozen objects. Together
with ES5/Strict function's encapsulation being protected even from
non-strict code, this enables the creation of tamper-proof objects. But only
if frozen objects cannot have their [[Prototype]] property changed out from
under them.



>
> As to the substantive issue: mutable __proto__ is something we would prefer
> not to have, but we are concerned about the compatibility issues. We look
> forward to hearing about Mozilla's experience with changing it.
>

In case this experiment does run into problems, what do you think about
Allen's proposed restriction: "That [[Prototype]] is guaranteed not to
change on an object for which [[Extensible]] is false."? This takes care of
the security issue I'm concerned about and won't break any old code.


>
> Personally, I think leaving "distasteful" but cross-browser features like
> this out of the spec in the hopes that they will wither away from neglect is
> a poor approach. If browsers feel pressured to implement such extensions for
> Web compatibility then we are not doing anyone any favors by leaving them in
> the domain of mutual reverse-engineering. I would prefer to see such
> features explicitly specified (with suitable restrictions) or explicitly
> forbidden, and perhaps explicitly deprecate them with the plan for further
> limits or outright removal in future versions of the spec. But it seems too
> late to make big changes in this regard for ES5.


Agreed.


> Maybe in the next version.
>

+100. An exhaustive list of such features should at least be enumerated in a
non-normative appendix. If they had, it wouldn't have taken us so long to
catch the mutable [[Prototype]] and F.caller issues. What other such issues
might we have missed?

In a closely related matter, we also need to tighten the Chapter 16
exemptions, as the presence of these exemptions precludes *any* sound
reasoning about JavaScript security. However, I have no clever ideas of what
such tighter language should say. Suggestions appreciated.

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


More information about the es-discuss mailing list