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

David Bruant bruant.d at gmail.com
Tue Nov 8 09:47:27 PST 2011


Le 08/11/2011 14:26, Andreas Rossberg a écrit :
> On 3 November 2011 23:55, Mark S. Miller <erights at google.com> wrote:
>>> If I understood Mark correctly, the features needed for SES are
>>> already part of ES.5 and are shipping in browsers
>>>
>>> (and hence don't bear upon future features).  Did I misunderstand?
>> These do bear on future features in three ways:
>>
>> 1) Future features could easily destroy all the security gains that ES5
>> achieved.
> I'm still trying to grasp the implications of the recent direct proxy
> proposal in this respect -- more precisely, its startTrapping
> functionality.
Just as a reminder, startTrapping really is not necessary to direct
proxies (Proxy.for) and should both should be considered independently
(even though they are on the same strawman)

> It seems to me that the ability to attach to a function, in
> particular, invalidates all current security guarantees, since it
> gives a whole new way of completely redefining any random function _in
> place_ by simply turning it into a function proxy. That is, even if
> that function is given by a non-writable binding or property!
"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.
Though, I agree about the non-writable binding. Something should be
added about that.
And it seems so much safer to prevent start trapping the global object
because things could get nasty otherwise.


> To achieve the effect of today's Object.{seal,freeze}, you hence also
> would have to make _every_ of the object's properties non-attachable.
> That is certainly possible, but seems considerably more fragile.And
> it still breaks the security of pre-existing SES code. IOW, I sense a
> security hazard.
I agree that there is a hazard but I am not sure it is that much bigger
than the opportunity for an attacker to redefine built-ins. This
opportunity exists since the origin of JavaScript (so before ES5 and SES).


> I also wonder about the effect that turning an (ordinary) object into
> a proxy would have on the visibility of private names. If one of the
> original methods accesses a private property on `this', then,
> according to the private names proposal, the handler only gets to see
> the .public property of that name. But can't this still leak
> information? The handler cannot use it to _read_ the existing property
> data, but it will still receive all future _writes_ to it.
>
> Am I missing something?
I don't think you are. I think you are right.
As said, the startTrapping proposal is controversial. Proxies are still
very new. I'm not sure it's wise to add the startTrapping.
If we ever realize that this is really needed, i don't think there is a
problem with adding it in a later ECMAScript version.

David


More information about the es-discuss mailing list