Proxy target/handler access leak in Node
erights at gmail.com
Mon Sep 17 16:50:51 UTC 2018
On Mon, Sep 17, 2018 at 8:32 AM Darien Valentine <valentinium at gmail.com>
> Thanks for the context, James. Yes, this thread mainly concerns the issue
> of being able to obtain references to values within the handler/target from
> external code, though I did try to make a case for not having the showProxy
> option in the original issue thread.
> I would also not have thought to call it an “attack” vector. Mark would be
> able to say better for sure though. It does make an invariant of the
> language violable though. It’s similar to exposing a function which, given
> only a function object, may return references to arbitrary values from that
> function’s scope.
> It’s similar to exposing a function which, given only a function object,
may return references to arbitrary values from that function’s scope.
This is an apt comparison. A debugger has access to such info. Likewise, in
a secure OS, when one process is able to debug another, the first process
can read any data from the address space of the second. There have even
been language implementations that were otherwise supposed to be memory
safe that had "peek" and "poke" operations for reading and writing
arbitrary memory locations from programs in the language. Of course, memory
allocators and garbage collectors typically need such access.
Whether these are "attacks" or "vulnerabilities" depends on how such
permission for debug-level access or peek/poke access is controlled and
>From a bit of web searching, I found the following worrisome:
seemingly in response to
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the es-discuss