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

Andreas Rossberg rossberg at google.com
Tue Nov 8 11:29:04 PST 2011


On 8 November 2011 18:47, David Bruant <bruant.d at gmail.com> wrote:
> "Given that direct proxies are not in a position to violate any of the
> *non-configurability or non-extensibility constraints* of their wrapped
> target, it should be safe to replace an existing normal object by a
> direct proxy wrapping that object."
> My understanding is that regarding the issue you mention, you cannot do
> more with startTrapping than redefining built-ins by (re)setting a property.

That may be true for plain objects, but I think the situation is quite
different for functions, because there is no equivalent to
"non-configurable" for the [[Call]] and [[Construct]] properties.


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.

/Andreas


More information about the es-discuss mailing list