Security and direct proxies (Was: Re: Lecture series on SES and capability-based security by Mark Miller)

Mark S. Miller erights at google.com
Tue Nov 8 11:46:57 PST 2011


On Tue, Nov 8, 2011 at 11:29 AM, Andreas Rossberg <rossberg at google.com>wrote:

> On 8 November 2011 19:13, Mark S. Miller <erights at google.com> wrote:
> > The reason Proxy.attach may not be fatal is that it only allows
> attachment
> > to extensible objects. Our hypothesis is that any ES5 object that is
> > interested in defending itself has already made itself non-extensible.
> This
> > is why we must key this off of non-extensibility, rather than
> introducing a
> > new orthogonal bit -- to avoid breaching the defenses of those ES5 era
> > objects that tried to defend themselves.
>
> I don't think that addresses the issue I was describing. The problem
> is: the object itself can all be frozen, non-extensible,
> non-attachable just fine, but that doesn't achieve much by itself
> anymore because an attacker can still attach to each individual
> method, since they are entirely separate objects!
>
> So instead of just freezing an object, you _additionally_ would have
> to make all its _individual methods_ non-attachable (by whatever
> means). AFAICS, that affects assumptions of existing ES5 code quite
> severely.


In general, for an object to be defensive, much of the surface reachable
from it by transitive prototype and reflective property traversal should
usually be frozen, and at least non-extensible. This is possible to express
in ES5 <
http://code.google.com/p/google-caja/source/browse/trunk/src/com/google/caja/ses/startSES.js#623>,
but inconvenient and expensive. That's why I have been advocating better
defensive abstractions for ES6: "const functions", "const classes",
"traitsjs" or its syntactic derivatives, etc.

Nevertheless, I see your point. Many defensive ES5 abstractions will be
less defensive than this. If I understand you correctly, your point is
specifically about the [[Call]] and [[Construct]] traps. Perhaps we should
be more conservative here, without necessarily backing away from the whole
Proxy.attach idea?

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


More information about the es-discuss mailing list