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: < http://code.google.com/p/es-lab/source/browse/trunk/src/proxies/FixedHandler.js > 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. Cheers, Tom 2011/6/22 Tom Van Cutsem <[email protected]> > 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 <[email protected]> > >> 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 >>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
