Membranes, unmediated access to objects through Object.getPrototypeOf

David Bruant bruant.d at gmail.com
Tue Oct 9 15:36:09 PDT 2012


Le 09/10/2012 19:52, Mark S. Miller a écrit :
> On Tue, Oct 9, 2012 at 6:25 AM, David Bruant <bruant.d at gmail.com
> <mailto:bruant.d at gmail.com>> wrote:
>
>     My point is that if the trap returns something else than the
>     original object, a defender who knows which object is expected can
>     know that either the object is a proxy or the genuine one, so it's
>     not that big of a deal to allow a different object.
>
>
> The typical use of a membrane is to separate two subgraphs that are
> not otherwise connected, except through the membrane and perhaps a
> small number of objects created and trusted by the spawner of the
> membrane. In my examples, Alice spawns a membrane so that she can give
> Bob mediated access to Carol, typically under the assumption that Bob
> and Carol are not otherwise connected. If this membrane maintains
> identity on each side as corresponding to identity on the other side,
> if maintains the illusion. Since neither Bob nor Carol are ever on
> both sides of the membrane, neither can do the comparison you suggest.
> This is as much a transparency issue as it is a security issue. Think
> of FF's use of membranes to separate frames. If the illusion broke, so
> would much software.
To summarize, to implement a proper membrane, we need to maintain the
illusion of the wrapped graph stability. This can be achieved today with
dummy proxies (with arguable downsides) as demonstrated by Tom.
The use of dummy targets is necessary to generate a graph isomorphic to
the original targets graph and respect the current identity-based
invariants.

>
>     If you don't (and won't) know the original object, what difference
>     does it make to be lied to if you can't ever know the truth?
>     As the dummy target example shows, actual identities don't make
>     much of a difference.
>
>
> I didn't follow that at all. It is a stability invariant which is
> being maintained. Much software in JS counts on object identity:
> indexOf, switch, WeakMaps, etc. If (Racket-like) state were maintained
> but identity were not, all these would break when a membrane is
> interposed.
If I (the attacker) first return some object o1 as prototype of o, then
o2 to Alice (defender). Of course, indexOf, switch, weakmaps, etc. don't
work "as expected", but that's a good thing. In making believe Bob that
Object.getPrototypeOf(o) is o2, I have been forced by the language to
create a new object with a different identity than o1, so Bob can know
i'm trying to lie to him or be inconsistent.
The good property the language provides here is that a malicious
attacker is forced to tell when it's attacking (by creating an object
with a different identity which can be compared with what's already
known thue revealing the attempt to fool).
It seems that additionally to this good property, what's wanted from the
language is to enforce what's returned in some cases and I question
whether it's a worthwhile addition to the current property (only for the
case of differenciating objects which have the same end-target).

>     In a way, what I'm asking is to make dummy target "official" and
>     more restricted, by not allowing arbitrary objects, but only
>     proxies with the actual target in their target chain.
>
>
> Making them more official and restricted sounds promising. But if I
> understand the rest of your sentence, what you're suggesting is not
> more restricted, it's differently restricted. And the way it is less
> restricted is, IMO, bad.
I see your point.
I realize that what I've written above about isomorphic graphs only
makes sense if we have a notion of equility.
Does end-target equality define a relevant isomorphism? Naively, I would
say yes, because comparing identity (through === or indirectly through
indexOf/WeakMap/Sets, etc.) can help detecting any attempt to deviate
from how the graph is supposed to be shaped, but it really isn't clear.

About making the restriction for membranes "official" could be done by
introducing "branded proxies" which output values (through
get/getOwnPropertyDescriptor/getPrototypeOf... traps) would also be
"branded proxies" (with the same brand). Brand validation would be
performed to ensure graph isomorphism. It ensures that you deviate from
the exact target, but only with a given proxy and only because you're
coming from a branded proxy (and not for no reason).
But as I describe it, I realize I'm describing somewhat native support
for membranes... so.. yeah... Maybe too early to suggest this.

David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20121010/8a851f63/attachment.html>


More information about the es-discuss mailing list