[Harmony proxies] Non-configurable properties: fixed properties VS trap all with invariants enforcement

Tom Van Cutsem tomvc.be at gmail.com
Wed Jun 22 01:14:48 PDT 2011


It just occurred to me that the security issues you describe re. fixed
properties & membranes may not be as bad as we first thought they were.


Because of the recursive wrapping of the membrane code, all of the
get/set/value attributes of fixed properties will contain wrappers
themselves. So, after revoking a membrane, untrusted code will still have
access to the structural information of these properties, but won't be able
to do anything useful with its values (they are revoked wrappers
themselves). The structural information itself does not convey any useful
authority to the untrusted code. The wrapper may still "leak" previously
exposed information (e.g. primitives are not wrapped), but the untrusted
code could retain access to this information regardless (even if we switched
to validating proxies).


So, long story short: I don't think proxies with fixed properties weaken the
actual security afforded by membranes, but I fully agree that the fact that
information is lingering in revoked proxies is surprising.


Cheers,

Tom

2011/6/21 Tom Van Cutsem <tomvc.be at gmail.com>

> Yes, you made a nice case. In a way I'm glad, as I wasn't too keen on the
> additional complexity brought about by the bicephal approach (membranes
> could still be made to work by converting all non-configurable properties
> into accessors as shown on the wiki page, at the price of giving up fully
> transparent wrappers)
>
> I guess the way forward is to try and specify precisely what consistency
> checks a proxy should perform, and how cheap or costly these will turn out
> to be.
>
> Re. untrusted code communicating via non-configurable, writable properties:
> I believe this is not a problem specific to proxies with fixed properties,
> or even proxies in general. As soon as you share a non-frozen object, this
> kind of communication can happen. But granted: membrane proxies +
> transparent fixed properties are flawed in this regard.
>
> Cheers,
> Tom
>
> 2011/6/20 Mark S. Miller <erights at google.com>
>
> Hi David, my compliments. This is an important issue I should have caught
>> but didn't notice. Thanks. I think agree with your conclusion (which I was
>> leaning towards anyway).
>>
>>
>> On Mon, Jun 20, 2011 at 10:25 AM, David Bruant <david.bruant at labri.fr>wrote:
>>
>>> Le 20/06/2011 17:15, David Bruant a écrit :
>>> > Hi,
>>> >
>>> > We may need to switch from the (bicephal) fixed properties model to a
>>> > "trap all with invariants enforcement" model.
>>> >
>>> > With the current simple membrane example:
>>> > -----
>>> > var o = {};
>>> > var s = makeSimpleMembrane(o);
>>> > var wrapper = s.wrapper,
>>> >     gate = s.gate;
>>> >
>>> > // ... later, in untrusted code (variable name kept for readability)
>>> > Object.defineProperty(wrapper, 'a', {value:1, configurable:false});
>>> >
>>> >
>>> > // ... later, back in trusted code:
>>> > gate.disable()
>>> >
>>> >
>>> > // ... later in the same untrusted code which had a reference to the
>>> > wrapper object.
>>> Actually, it's more convincing if the wrapper is given to another piece
>>> of untrusted code, because this code should not have access to what
>>> another untrusted code added to the wrapper AFTER disabling. Also,
>>> untrusted code could communicate through non-configurable, but writable
>>> properties which doesn't sounds good.
>>>
>>> > wrapper.a; // 1 in the fixed properties model
>>> > // throw if the 'get' traps was actually called.
>>> > // Such a difference is certainly noticeable in all traps.
>>> > -----
>>> >
>>> > The problem with the fixed property model is that properties exist on
>>> > the proxy object itself with no way to control (and prevent in our
>>> > case) access to them.
>>> >
>>> > David
>>> > _______________________________________________
>>> > es-discuss mailing list
>>> > es-discuss at mozilla.org
>>> > https://mail.mozilla.org/listinfo/es-discuss
>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>
>>
>>
>> --
>>     Cheers,
>>     --MarkM
>>
>> _______________________________________________
>> es-discuss mailing list
>> es-discuss at mozilla.org
>> https://mail.mozilla.org/listinfo/es-discuss
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110622/b8108b4a/attachment.html>


More information about the es-discuss mailing list