Another de-facto insecurity we need to fix in ES5

Mark S. Miller erights at google.com
Wed Jun 17 15:34:11 PDT 2009


On Mon, Jun 15, 2009 at 9:23 PM, Brendan Eich <brendan at mozilla.com> wrote:

> For ES5, this is a tempest in a teapot.
> We at Mozilla are trying to remove assignable __proto__ in a near-term
> release,
>

Hi Brendan, this is wonderful news!

As reason for skepticism, our v8 folk cite

<http://www.google.dk/codesearch?q="__proto__+%3D+"+lang:javascript<http://www.google.dk/codesearch?q=%22__proto__+%3D+%22+lang:javascript>
>

Nevertheless, I'm pleased to report that our v8 folks agree that if Mozilla
does this and does not back off because of compatibility problems, they will
do so as well. Thanks for being brave enough to jump into this pool first!



> except in these two useful and (AFAIK) safe cases:
>
> * A newborn with no other properties.
>

For an object that never comes to have any own properties, when is it no
longer a newborn?  For example

    function Token() {}
    var tok = new Token();

Is the newly created object still a newborn by the time it gets assigned to
tok?



>
> * A recent-born in the midst of initialization via evaluation of its object
> initialiser syntax, where the baby object can't escape, can't be referenced
> to make a cycle, etc.
>

How does this arise?

In both cases, would it be true that by the time Object.freeze(x) or
Object.preventExtensions(x) returns that x no longer has a mutable
[[Prototype]]? If so, then you're plans are already conformant to either my
original suggestion or Allen's improved version.


We really don't want to continue supporting mutating __proto__ in other
> cases. Assignable __proto__ is a hugely expensive operation that breaks all
> sorts of optimizations, requiring fairly expensive deoptimization effort.
>

I love it when performance, integrity, and security all line up on the same
side of an issue ;).


>
> ES5's Object.create relieves the need for any of this, but legacy code
> won't be rewritten all at once, so we're probably going to support the above
> two bulleted cases.
>

Given that this already isn't a problem for IE and Opera, that v8 follows
your lead, and assuming that Apple does as well -- so that these two remain
the only exceptions -- do you recommend that the spec adopt stronger
wording? (I would find this attractive as well.) Any suggestions for what
this stronger wording might be?


>
> The idea that the ES5 spec suddenly makes the world more secure by trying
> circuitously to address old extensions such as __proto__ seems optimistic to
> me. Better to get rid of the offending extension than try to fence it while
> not speaking its (I mean ES-unspecififed __proto__'s) name.
>

Certainly! But until we see how your experiment goes (best of luck!) I am
proceeding under the pessimistic assumption that we can't get rid of the
offending extension from all ES5 implementations. I'd love to be proven
wrong.


>
> But this is a job for implementors, not the spec. Implementors jumped in
> when the standards process stalled after ES3. Blame them for trying, or
> failing to design high-integrity APIs, but it's all spilled milk. They need
> to clean it up, 'sall (I say this as one of "them").
>
> The bigger picture must involve implementations as well as the spec, and
> de-facto standards that may precede de-jure replacements or adoptions of
> de-facto standards. It isn't as if ES5 is the last time there will be a
> de-facto mess to clean up, although members of the committee are making good
> promises and progress in sharing intentions and prototypes.
>

When implementations have bad features in common with each other, as
with F.caller, then some cross-browser code will have come to rely on
that feature. Then, even if each browser vendor individually believes that
the web
would be better off without that feature, they are in the normal
browser competitive bind removing the feature. That's one of the major
purposes of standards committees -- to get de-jure agreement on
changes that all would like to make but that each would be punished
for making by themselves. I think this accurately describes why we
needed a de-jure poison pill for F.caller.


> 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?


> Beyond this point, implementations will have bugs, whether in would-be
> de-facto extensions to the standard, or in standardized components --
> forever. Attempts to inject security by code transformations (which of
> course can themselves be buggy) will simply have to try to work around
> browser JS engine bugs.
>

Sure. However, some such bugs can cause severe problems. I am trying to
catch as many as I notice in ES5 before ES5 is set in stone. Given the
expanded threat model ES5 seems to enable (see the "Future defensibility
from untranslated code" section at the bottom of <
http://code.google.com/p/google-caja/wiki/NiceNeighbor>), the F.caller
issue, had it not been caught in time, would have cost us a factor of two in
performance. The present issue, if unfixed, may well preclude this expansion
of our threat model except on ES5 implementations that happen not to have
this problem.


>
> Security is never done, because it consists of end-to-end and many-layers
> property enforcement problems, where the evolving system and economic
> scarcity mean the bad guys always have a new layer or middle-man that's
> under-defended to attack. Denning said this in her 1999 Infosec award
> speech, and it seems unassailable, even if it outrages some of my academic
> research friends.
>

Btw, here's an academic paper you may enjoy that agrees with you and Denning
on the layering point <http://www.erights.org/talks/no-sep/> ;).


>
> Better JS security will have to come from the browsers fixing bugs and
> breaking compatibility, where the alternative is an ongoing security hazard
> that's actually exploited. When it comes to both bad old default security
> policies, and some of the extensions added over the years, I say: break the
> web, or at least bend it! My new mantra. Shocking, I know, but with
> minority-share browsers now getting close to modern-IE by-version market
> share, isn't it time?
>

I sincerely applaud this bold stance. If Mozilla proceeds in this manner
successfully, then the present issue becomes a non-concern; as probably do
several more we haven't stumbled across yet. Please let us know what we can
do to help you succeed on this quest. Really. And thanks again!

-- 
   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es5-discuss/attachments/20090617/4d24f080/attachment-0001.html>


More information about the es5-discuss mailing list