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

Tom Van Cutsem tomvc.be at gmail.com
Sun Jul 3 05:59:55 PDT 2011

As a follow-up to the fixed properties proposal:

I created a prototype implementation of fixed properties on top of the
existing Proxy API. The idea is to wrap an existing proxy handler in a
FixedHandler. This FixedHandler does the bookkeeping and checking to ensure
that the wrapped handler doesn't misreport non-configurable properties.

Full source code available here: <

I also adapted David Bruant's self-hosted implementation of Arrays using
Proxies <https://github.com/DavidBruant/ProxyArray> to use the above
FixedHandler. Things appear to work out nicely: <
https://github.com/tvcutsem/ProxyArray> is a self-hosted implementation of
Arrays using proxies with fixed properties.

"length" appears to be faithfully emulated, but this could use more testing.
See <https://github.com/tvcutsem/ProxyArray/blob/master/Arrays.html> for an
initial testcase.


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

> 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/20110703/2a9a92f4/attachment-0001.html>

More information about the es-discuss mailing list