Darien Valentine (2018-09-17T01:19:25.000Z)
valentinium at gmail.com (2018-09-17T01:27:08.530Z)
> 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, in `formatValue`: 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` (via `formatValue` again), but that property may have been previously overwritten from user code: https://github.com/nodejs/node/blob/master/lib/util.js#L566-L580 https://github.com/nodejs/node/blob/master/lib/util.js#L628 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.
valentinium at gmail.com (2018-09-17T01:26:33.680Z)
> 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` (via `formatValue`), but that property may have been previously overwritten from user code: https://github.com/nodejs/node/blob/master/lib/util.js#L566-L580 https://github.com/nodejs/node/blob/master/lib/util.js#L628 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.
valentinium at gmail.com (2018-09-17T01:26:24.263Z)
> 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` (via `formatValue`), but that property may have been previously overwritten from user code: https://github.com/nodejs/node/blob/master/lib/util.js#L566-L580 https://github.com/nodejs/node/blob/master/lib/util.js#L628 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.
valentinium at gmail.com (2018-09-17T01:25:19.399Z)
> 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` (via `formatValue`), 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.
valentinium at gmail.com (2018-09-17T01:20:49.412Z)
> 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.