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

Tom Van Cutsem tomvc.be at gmail.com
Wed Jun 22 11:28:10 PDT 2011


We haven't actually revisited the membrane code in light of the fixed
properties strawman.

One change that I can imagine being made, is that a membrane wrapper, when
first created, explicitly copies over the non-configurable properties of its
target (this is similar to what the "wrap" method does in <
http://wiki.ecmascript.org/doku.php?id=strawman:fixed_properties>). After
this initialization, the handler can set a flag that disallows any further
properties to be defined via the defineProperty trap. That would disallow
untrusted code from defining new properties on the wrapper.

Regardless of whether this would work or not: it sure is introducing a lot
of complexity in the already complex membrane code, which is not what I
would call progress!

Cheers,
Tom

2011/6/22 David Bruant <david.bruant at labri.fr>

> Le 22/06/2011 10:14, Tom Van Cutsem a écrit :
>
>
>> 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.
>>
>>  It does leak that the property exists (because a value is returned
> instead of throwing inconditionally). It doesn't sound very dangerous and
> exploitable, but it's a leak.
>
>
>
>  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).
>>
>>  The wrapper can also leak previously unexposed information (not for one
> piece of untrusted code, but at least two). That was the point of the
> adjustement of my example:
> ( 0) Untrusted code 1 and 2 have a reference to the wrapper w )
> 1) Untrusted code 1 does: Object.defineProperty(w, 'p',
> {configurable:false, value:1})
> 2) Trusted code closes the gate
> 3) In Untrusted code 2: 'p' in w === true
>
> Before 1), this 'p' property wasn't exposed to Untrusted code 2. Closing
> the gate on 2) should prevent everyone (like Untrusted code 2) who hadn't
> seen 'p' before gate-closing to see it afterward. It is not big, but it
> allows two pieces of untrusted code to communicate (more than they would if
> the trap was called and threw right away).
>
> The easy workaround is to hand a different wrappers to different untrusted
> codes, but duplicating the number of necessary objects to guarantee security
> is an unfortunate workaround.
>
> David
>
>
>> 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
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20110622/2069072d/attachment.html>


More information about the es-discuss mailing list