Vm2: Any reason why most builtin modules are proxied rather than being required in the sandbox?

Created on 17 Oct 2017 · 5Comments · Source: patriksimek/vm2

Hi,
I'm trying to figure out why builtin modules are proxied from the host and not being required in the vm.

this is my setup currently:

const vm = new NodeVM({
        require: {
            external: true,
            context: 'sandbox',
            builtin: ['*'],
        },
    });

vm.run(...);

inside the VM I require an external module (axios if that matters) and in the chain of dependencies it requires another module (follow-redirects) that does this (more or less):

var Writable = require('stream').Writable;

function RedirectableRequest(options, responseCallback) {
// .....
}

RedirectableRequest.prototype = Object.create(Writable.prototype);

RedirectableRequest.prototype._performRequest = function () {  // <-------- this line breaks
// ..........
}

running this code inside the vm throws: TypeError: 'set' on proxy: trap returned falsish for property '_performRequest'.
The stream object is being proxied to the vm.

running this code when stream is being actually required inside the vm (by removing the if statement here: https://github.com/patriksimek/vm2/blob/master/lib/sandbox.js#L133) is working.

running node 6.10.3 on osx.

Thanks

stale

Source

ozsay

👍3

Most helpful comment

I also found an alternative solution (one I think fits the paradigm better).

Basically what I found was contextified code was trying to write to a prototype of an object it created in its context, but which extended an object brought in from another context.

Per the documentation on the set proxy handler, if the property does not exist on the object you are trying to set, the prototype set handler will be called.

So;
Object
prototype
a <-Setting this (which actually doesn't exist on prototype)
__proto__ (proxy)
set: (){} <- Actually calls this

And when the set handler is called, the receiver argument will be set to the original object we were trying to set on. My solution was this:

--- a/node_modules/vm2/lib/contextify.js
+++ b/node_modules/vm2/lib/contextify.js
@@ -17,7 +17,23 @@ const DEBUG = false;
 const OPNA = 'Operation not allowed on contextified object.';
 const ERROR_CST = Error.captureStackTrace;
 const FROZEN_TRAPS = {
-   set: (target, key) => false,
+   set: (target, key, value, receiver) => {
+       if( target !== receiver ){
+
+           Object.defineProperty(receiver, key, {
+               value: value,
+               writable: true,
+               enumerable: true,
+               configurable: true
+           })
+
+           return true;
+
+       }
+
+       return false;
+
+   },

tcf909 on 5 May 2018

👍3

All 5 comments

related to #127

tcf909 on 8 Apr 2018

I went ahead and changed the if statement to:

if( vm.options.require.context === 'sandbox' && modulename !== 'async_hooks' ){

I found that in node 8.x I ran in to issues with async_hooks

tcf909 on 5 May 2018

I also found an alternative solution (one I think fits the paradigm better).

Basically what I found was contextified code was trying to write to a prototype of an object it created in its context, but which extended an object brought in from another context.

Per the documentation on the set proxy handler, if the property does not exist on the object you are trying to set, the prototype set handler will be called.

So;
Object
prototype
a <-Setting this (which actually doesn't exist on prototype)
__proto__ (proxy)
set: (){} <- Actually calls this

And when the set handler is called, the receiver argument will be set to the original object we were trying to set on. My solution was this:

--- a/node_modules/vm2/lib/contextify.js
+++ b/node_modules/vm2/lib/contextify.js
@@ -17,7 +17,23 @@ const DEBUG = false;
 const OPNA = 'Operation not allowed on contextified object.';
 const ERROR_CST = Error.captureStackTrace;
 const FROZEN_TRAPS = {
-   set: (target, key) => false,
+   set: (target, key, value, receiver) => {
+       if( target !== receiver ){
+
+           Object.defineProperty(receiver, key, {
+               value: value,
+               writable: true,
+               enumerable: true,
+               configurable: true
+           })
+
+           return true;
+
+       }
+
+       return false;
+
+   },

tcf909 on 5 May 2018

👍3

Whats the status? Project dead?

TheAifam5 on 5 Aug 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.