Le 25/06/2012 17:36, Allen Wirfs-Brock a écrit :
On Jun 22, 2012, at 11:01 AM, David Bruant wrote:
...
There is a potential security issue. From the wiki [1] (in the case
where the instance is a proxy trapping on instanceof): "Security issue:
the handler is given a reference to the function object (the right-hand
side of the instanceof operator). This gives the handler the ability to
generate new instances of that function. "
I note that the referenced material[1] is part of the original Proxy proposal
and not the current direct proxy proposal. I may be missing something here,
but with direct proxies every handler is passed a reference to its target
object and hence if the target is a constructable function the handler might
generate an instance of it. Given that, I don't see why an instanceof trap
exposes any more than any other trap.
The potential leak could arise when you test instanceof (in the naive
hasInstance trap case) with something that wasn't created through the
constructor, like:
mySecretObject instanceof SomePotentiallyUntrustedConstructor
And I agree with you, the constructor has "full power" over instances it
generates. The constructor doesn't even need to be a proxy for that.
In my opinion, the issue stands if the choice is to have either the LHS
or RHS of instanceof to trap on instanceof. The more general issue isn't
about generating new instances, but about an object gaining access to
another object it didn't have access to before the instanceof
evaluation. Both cases result in a capability leak.
To be more precise, currently, when you write "a instanceof b", you
don't expect either a or b to leak. This property should probably be
preserved even with proxies.
You are probably correct about the expectation, but it doesn't reflect what is
actually specified by ES<=5.1.
Does it matter? [[HasInstance]] is a specification internal mechanism.
There is nothing preventing from re-specifying it (like I suggested in
my proposal as an example) as long as it keeps backward compatibility.
The same probably goes for any internal method.
It's actually the last time this can be done, because proxies will
expose a lot of the internal machinery to user code.
The normal specified implementations of instanceof or any other polymorphic
internal methods don't leak (except in ways fundamental to their normal
behavior). However, there are no guarantees that host object implementations
of those methods won't leak.
My understanding of the "let's get rid of host objects" is to enable
having such guarantees. Is getting rid of host objects a goal? By
"getting rid of", I mean "making what used to be host objects at worst
as powerful as proxies".
Specifically, in my proposal, I have redrawn the interface available to
proxies when it comes to reifying instanceof. If host objects weren't
more powerful than proxies and my proposal (or any equivalent) were to
be accepted, then user code would be guaranteed that "host objects"
won't leak things they're not supposed to.
Similarly, any value that is reified for use by a Proxy handler could be leaked
by the handler. Once such values are presented to externally provided code I
don't see how you have any assurance that such code won't pass those values on
in ways that you didn't anticipate.
With my proposal, you can check instanceof with an arbitrary untrusted
constructor and your objects won't leak (I built it for that purpose).
Assuming my proposal is in, could you write a malicious constructor C
that acquires a reference to an object o with only the line 'o
instanceof C' and no other interaction between o and C? I'm convinced
it's not possible, but maybe I'm wrong. This exercice will either point
to a defect in my proposal or help understanding it better, both being a
step forward :-)
David
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
