Proxy target/handler access leak in Node

Isiah Meadows isiahmeadows at gmail.com
Mon Sep 17 01:57:15 UTC 2018


In the browser, I could see why not to allow it by default: it's a
potential security hole, and GC concerns do exist (what happens if the
symbol's data is no longer accessible without reflection?).

In embeddings, I'm not sure if there's any real problem, considering
Node's `vm` API allows proper sandboxing to prevent scripts from
getting ahold of a `util` object in the first place, and by extension,
the private data assigned to it.

It might be worth accepting a level of non-determinism within the spec
stating that if a symbol is deemed not accessible by the
implementation, they aren't required to return it. Objects would have
to hold those private symbols weakly, but the non-determinism would
need to clarified with the weak ref proposal. (This is primarily a
concern with private symbols, and an implementation might choose not
to expose that in the first place, even to embedders.)

-----

Isiah Meadows
contact at isiahmeadows.com
www.isiahmeadows.com

On Sun, Sep 16, 2018 at 9:19 PM Darien Valentine <valentinium at gmail.com> wrote:
>
> > What is going on here? Can you explain?
>
> A C++/V8 API is used to obtain references to the target and handler from only the proxy object, even though those objects aren’t supposed to be available to this ES scope:
>
> https://github.com/nodejs/node/blob/master/lib/util.js#L642-L647
>
> The pair of objects is passed to another function, which in turn may pass values to the method "ctx.stylize", but that property may have been previously overwritten from user code:
>
> https://github.com/nodejs/node/blob/master/lib/util.js#L566-L580
>
> AFAICT, fixing the leak (beyond util.js) would be possible by making `stylize` unconfigurable/unwritable. However there may be other avenues here — I’m not sure.
>
> > Does that mean this attack is impossible from code loaded into a new realm as made by the shim or SES?
>
> The exploit isn’t sensitive to realm-of-origin, since util is using v8 internals to get the references, not e.g. a patched version of Proxy. But it still depends on the proxy object in question being exposed to a context where util.inspect exists.
>
> In the [issue comment](https://github.com/nodejs/node/issues/10731#issuecomment-419008987), I wrote this:
>
> > This exploit can be fixed pretty easily. But I think it’s symptomatic. My understanding was that V8’s C++ APIs are intended for making external functionality available to ECMAScript using ECMAScript values and ECMAScript semantics. Here though, it is being used to bypass ECMAScript semantics. The behavior seen in the above script isn’t possible in ECMAScript — but neither is distinguishing between objects which have been implemented as ordinary objects and objects implemented as proxy exotic objects.
>
>
> On Sun, Sep 16, 2018 at 8:06 PM Mark Miller <erights at gmail.com> wrote:
>>
>> This is indeed quite scary. I have never used of explored the Node `util` API. What is going on here? Can you explain?
>>
>> The Realms shim and SES (which build on the Realms shim) create an environment in which only those globals defined by EcmaScript, not by the host, are present by default.
>> https://github.com/Agoric/SES/tree/master/demo
>> https://rawgit.com/Agoric/SES/master/demo/
>> Does that mean this attack is impossible from code loaded into a new realm as made by the shim or SES?
>>
>>
>>
>> On Sun, Sep 16, 2018 at 12:10 PM Mike Samuel <mikesamuel at gmail.com> wrote:
>>>
>>> Nicely done!
>>>
>>> One more reason to prefer WeakMaps to properties when relating objects and secrets.
>>>
>>>
>>>
>>> On Sun, Sep 16, 2018 at 2:59 PM Darien Valentine <valentinium at gmail.com> wrote:
>>>>
>>>> A few weeks ago I’d commented on an open Node github issue regarding Proxies and inspection. While the bulk of the comment concerns an opinion that proxies should not be treated as special case, I included an example of a mechanism by which the current implementation allows outside code to access the target and handler objects of a proxy that it does not own.
>>>>
>>>> On reflection I realized this specific issue might be worth drawing more attention to.
>>>>
>>>> ```js
>>>> const util = require('util');
>>>>
>>>> const victim = new Proxy({}, {
>>>>   SECRET: 'Nothing outside can access this'
>>>> });
>>>>
>>>> let secret;
>>>>
>>>> const invariantViolator = {
>>>>   [util.inspect.custom](depth, options) {
>>>>     const { stylize } = options;
>>>>
>>>>     options.showProxy = true;
>>>>
>>>>     options.stylize = (value, color) => {
>>>>       secret = value;
>>>>       options.stylize = stylize;
>>>>       return stylize(value, color);
>>>>     };
>>>>
>>>>     return victim;
>>>>   }
>>>> };
>>>>
>>>> util.inspect(invariantViolator);
>>>>
>>>> console.log(secret); // 'Nothing outside can access this'
>>>> ```
>>>>
>>>> The implication is that even if running Node with no C++ addons, it is presently possible for proxies to be violated using just the standard lib, which may be significant from a security perspective. I’m not sure if that’s the case in practice, but just in case, I figured I should try to get eyes on it.
>>>>
>>>> Note that even if this particular hole is patched, the "analog hole" (so to speak) of just analyzing the string output remains.
>>>> _______________________________________________
>>>> 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


More information about the es-discuss mailing list