Proxy target/handler access leak in Node

Darien Valentine valentinium at gmail.com
Mon Sep 17 17:44:29 UTC 2018


> Making is a public symbol in this manner means it is almost impossible to
deny. It is still true that "util" is deniable, so this isn't necessarily
fatal. I am not yet oriented enough to understand what the consequences are
of suppressing util; but I am worried.

I wasn’t under the impression that the util.inspect.custom symbol or the
functionality it provides is itself problematic. It just happens to be
possible to use it, currently, to get inside the proxy target/handler
because its second argument is an object with a property whose value is a
function that can be called with proxy target / handler values, yet that
property may be overwritten by user code. This is very unlikely to have
been an intentional facet of the API, so making `opts.stylize`
unwritable/unconfigurable shouldn’t reduce the usefulness of custom inspect
implementations, and afaict this would block off the avenue by which
references to target/handler can escape util.js.

Is there another reason why the util.inspect.custom symbol contract would
be an issue?

On Mon, Sep 17, 2018 at 1:21 PM Mark Miller <erights at gmail.com> wrote:

> > The Node.js trust model assumes that all code is trusted.
>
> First I want to respond to this sentence out of context. I often hear such
> phrases. I know what people mean by this, but the phrase "trusted" here
> *always* leads to confusion and muddy thinking. I don't trust the code I
> wrote yesterday. Instead, what we mean by this is something like:
>
> "The Node.js xxxx model assumes we are fully vulnerable to all code."
>
> This phrasing helps us notice some of the questions made obscure by the
> earlier phrase. What is fully vulnerable to which code? What is meant in
> this case is presumably something more like
>
> "...assumes the Node.js process is fully vulnerable to all code it is
> asked to run."
>
> Under a traditional OS, a process executes as the account (or "user")
> executing that process, and has all the permissions of that user. So this
> becomes:
>
> "...assumes the user is fully vulnerable to all code that any Node process
> executing as that user is asked to run."
>
> (Which of course includes anything built on Electron, which makes the
> situation even worse in some ways.)
>
> Given the way that this body of code is typically selected, by transitive
> alleged package dependencies, this is a ridiculously large attack surface.
> Fortunately, there is increasing appreciation that such pervasive
> vulnerability is problematic.
>
> See
>
> https://www.youtube.com/watch?v=9Snbss_tawI&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=23
>
> Also relevant
>
> https://www.youtube.com/watch?v=wQHjITxQX0g&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=18
>
> https://www.youtube.com/watch?v=9WdbTucMaRo&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=10
>
> https://www.youtube.com/watch?v=pig-sIS8_Wc&list=PLKr-mvz8uvUgybLg53lgXSeLOp4BiwvB2&index=20
>
> --
>   Cheers,
>   --MarkM
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20180917/26e52774/attachment-0001.html>


More information about the es-discuss mailing list