npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2024 – Pkg Stats / Ryan Hefner

@palerock/vm2

v3.9.4

Published

update from vm2

Downloads

4

Readme

vm2 NPM Version NPM Downloads Package Quality Travis CI Known Vulnerabilities

vm2 is a sandbox that can run untrusted code with whitelisted Node's built-in modules. Securely!

Features

  • Runs untrusted code securely in a single process with your code side by side
  • Full control over sandbox's console output
  • Sandbox has limited access to process's methods
  • Sandbox can require modules (builtin and external)
  • You can limit access to certain (or all) builtin modules
  • You can securely call methods and exchange data and callbacks between sandboxes
  • Is immune to all known methods of attacks
  • Transpilers support

How does it work

  • It uses internal VM module to create secure context
  • It uses Proxies to prevent escaping the sandbox
  • It overrides builtin require to control access to modules

What is the difference between Node's vm and vm2?

Try it yourself:

const vm = require('vm');
vm.runInNewContext('this.constructor.constructor("return process")().exit()');
console.log('Never gets executed.');
const {VM} = require('vm2');
new VM().run('this.constructor.constructor("return process")().exit()');
// Throws ReferenceError: process is not defined

Installation

IMPORTANT: Requires Node.js 6 or newer.

npm install vm2

Quick Example

const {VM} = require('vm2');
const vm = new VM();

vm.run(`process.exit()`); // TypeError: process.exit is not a function
const {NodeVM} = require('vm2');
const vm = new NodeVM({
    require: {
        external: true
    }
});

vm.run(`
    var request = require('request');
    request('http://www.google.com', function (error, response, body) {
        console.error(error);
        if (!error && response.statusCode == 200) {
            console.log(body) // Show the HTML for the Google homepage.
        }
    })
`, 'vm.js');

Documentation

VM

VM is a simple sandbox, without require feature, to synchronously run an untrusted code. Only JavaScript built-in objects + Buffer are available. Scheduling functions (setInterval, setTimeout and setImmediate) are not available by default.

Options:

  • timeout - Script timeout in milliseconds.
  • sandbox - VM's global object.
  • compiler - javascript (default) or coffeescript or custom compiler function. The library expects you to have coffee-script pre-installed if the compiler is set to coffeescript.
  • eval - If set to false any calls to eval or function constructors (Function, GeneratorFunction, etc) will throw an EvalError (default: true).
  • wasm - If set to false any attempt to compile a WebAssembly module will throw a WebAssembly.CompileError (default: true).
  • fixAsync - If set to true any attempt to run code using async will throw a VMError (default: false).

IMPORTANT: Timeout is only effective on synchronous code you run through run. Timeout is NOT effective on any method returned by VM. There're some situations when timeout doesn't work - see #244.

const {VM} = require('vm2');

const vm = new VM({
    timeout: 1000,
    sandbox: {}
});

vm.run("process.exit()"); // throws ReferenceError: process is not defined

You can also retrieve values from VM.

let number = vm.run("1337"); // returns 1337

TIP: See tests for more usage examples.

NodeVM

Unlike VM, NodeVM lets you require modules same way like in regular Node's context.

Options:

  • console - inherit to enable console, redirect to redirect to events, off to disable console (default: inherit).
  • sandbox - VM's global object.
  • compiler - javascript (default) or coffeescript or custom compiler function (which receives the code, and it's filepath). The library expects you to have coffee-script pre-installed if the compiler is set to coffeescript.
  • eval - If set to false any calls to eval or function constructors (Function, GeneratorFunction, etc) will throw an EvalError (default: true).
  • wasm - If set to false any attempt to compile a WebAssembly module will throw a WebAssembly.CompileError (default: true).
  • sourceExtensions - Array of file extensions to treat as source code (default: ['js']).
  • require - true or object to enable require method (default: false).
  • require.external - true, an array of allowed external modules or an object (default: false).
  • require.external.modules - Array of allowed external modules. Also supports wildcards, so specifying ['@scope/*-ver-??], for instance, will allow using all modules having a name of the form @scope/something-ver-aa, @scope/other-ver-11, etc.
  • require.external.transitive - Boolean which indicates if transitive dependencies of external modules are allowed (default: false).
  • require.builtin - Array of allowed builtin modules, accepts ["*"] for all (default: none).
  • require.root - Restricted path(s) where local modules can be required (default: every path).
  • require.mock - Collection of mock modules (both external or builtin).
  • require.context - host (default) to require modules in host and proxy them to sandbox. sandbox to load, compile and require modules in sandbox. Builtin modules except events always required in host and proxied to sandbox.
  • require.import - Array of modules to be loaded into NodeVM on start.
  • require.resolve - An additional lookup function in case a module wasn't found in one of the traditional node lookup paths.
  • nesting - true to enable VMs nesting (default: false).
  • wrapper - commonjs (default) to wrap script into CommonJS wrapper, none to retrieve value returned by the script.
  • argv - Array to be passed to process.argv.
  • env - Object to be passed to process.env.
  • strict - true to loaded modules in strict mode (default: false).

IMPORTANT: Timeout is not effective for NodeVM so it is not immune to while (true) {} or similar evil.

REMEMBER: The more modules you allow, the more fragile your sandbox becomes.

const {NodeVM} = require('vm2');

const vm = new NodeVM({
    console: 'inherit',
    sandbox: {},
    require: {
        external: true,
        builtin: ['fs', 'path'],
        root: "./",
        mock: {
            fs: {
                readFileSync() { return 'Nice try!'; }
            }
        }
    }
});

// Sync

let functionInSandbox = vm.run("module.exports = function(who) { console.log('hello '+ who); }");
functionInSandbox('world');

// Async

let functionWithCallbackInSandbox = vm.run("module.exports = function(who, callback) { callback('hello '+ who); }");
functionWithCallbackInSandbox('world', (greeting) => {
    console.log(greeting);
});

When wrapper is set to none, NodeVM behaves more like VM for synchronous code.

assert.ok(vm.run('return true') === true);

TIP: See tests for more usage examples.

Loading modules by relative path

To load modules by relative path, you must pass full path of the script you're running as a second argument of vm's run method if the script is a string. Filename then also shows up in any stack traces produced from the script.

vm.run("require('foobar')", "/data/myvmscript.js");

If the script you are running is an VMScript, the path is given in the VMScript constructor.

const script = new VMScript("require('foobar')", {filename: "/data/myvmscript.js"});
vm.run(script);

VMScript

You can increase performance by using pre-compiled scripts. The pre-compiled VMScript can be run later multiple times. It is important to note that the code is not bound to any VM (context); rather, it is bound before each run, just for that run.

const {VM, VMScript} = require('vm2');

const vm = new VM();
const script = new VMScript("Math.random()");
console.log(vm.run(script));
console.log(vm.run(script));

Works for both VM and NodeVM.

const {NodeVM, VMScript} = require('vm2');

const vm = new NodeVM();
const script = new VMScript("module.exports = Math.random()");
console.log(vm.run(script));
console.log(vm.run(script));

Code is compiled automatically first time you run it. You can compile the code anytime with script.compile(). Once the code is compiled, the method has no effect.

Error handling

Errors in code compilation and synchronous code execution can be handled by try/catch. Errors in asynchronous code execution can be handled by attaching uncaughtException event handler to Node's process.

try {
    var script = new VMScript("Math.random()").compile();
} catch (err) {
    console.error('Failed to compile script.', err);
}

try {
    vm.run(script);
} catch (err) {
    console.error('Failed to execute script.', err);
}

process.on('uncaughtException', (err) => {
    console.error('Asynchronous error caught.', err);
})

Debugging a sandboxed code

You can debug/inspect code running in the sandbox as if it was running in a normal process.

  • You can use breakpoints (requires you to specify a script file name)
  • You can use debugger keyword.
  • You can use step-in to step inside the code running in the sandbox.

Example

/tmp/main.js:

const {VM, VMScript} = require('.');
const fs = require('fs');
const file = `${__dirname}/sandbox.js`;

// By providing a file name as second argument you enable breakpoints
const script = new VMScript(fs.readFileSync(file), file);

new VM().run(script);

/tmp/sandbox.js

const foo = 'ahoj';

// Debugger keyword works just fine anywhere.
// Even without specifying a file name to the VMScript object.
debugger;

Read-only objects (experimental)

To prevent sandboxed script to add/change/delete properties to/from the proxied objects, you can use freeze methods to make the object read-only. This is only effective inside VM. Frozen objects are affected deeply. Primitive types can not be frozen.

Example without using freeze:

const util = {
    add: (a, b) => a + b
}

const vm = new VM({
    sandbox: {util}
});

vm.run('util.add = (a, b) => a - b');
console.log(util.add(1, 1)); // returns 0

Example with using freeze:

const vm = new VM(); // Objects specified in sandbox can not be frozen.
vm.freeze(util, 'util'); // Second argument adds object to global.

vm.run('util.add = (a, b) => a - b'); // Fails silently when not in strict mode.
console.log(util.add(1, 1)); // returns 2

IMPORTANT: It is not possible to freeze objects that has already been proxied to the VM.

Protected objects (experimental)

Unlike freeze, this method allows sandboxed script to add/modify/delete properties on object with one exception - it is not possible to attach functions. Sandboxed script is therefore not able to modify methods like toJSON, toString or inspect.

IMPORTANT: It is not possible to protect objects that has already been proxied to the VM.

Cross-sandbox relationships

const assert = require('assert');
const {VM} = require('vm2');

const sandbox = {
    object: new Object(),
    func: new Function(),
    buffer: new Buffer([0x01, 0x05])
}

const vm = new VM({sandbox});

assert.ok(vm.run(`object`) === sandbox.object);
assert.ok(vm.run(`object instanceof Object`));
assert.ok(vm.run(`object`) instanceof Object);
assert.ok(vm.run(`object.__proto__ === Object.prototype`));
assert.ok(vm.run(`object`).__proto__ === Object.prototype);

assert.ok(vm.run(`func`) === sandbox.func);
assert.ok(vm.run(`func instanceof Function`));
assert.ok(vm.run(`func`) instanceof Function);
assert.ok(vm.run(`func.__proto__ === Function.prototype`));
assert.ok(vm.run(`func`).__proto__ === Function.prototype);

assert.ok(vm.run(`new func() instanceof func`));
assert.ok(vm.run(`new func()`) instanceof sandbox.func);
assert.ok(vm.run(`new func().__proto__ === func.prototype`));
assert.ok(vm.run(`new func()`).__proto__ === sandbox.func.prototype);

assert.ok(vm.run(`buffer`) === sandbox.buffer);
assert.ok(vm.run(`buffer instanceof Buffer`));
assert.ok(vm.run(`buffer`) instanceof Buffer);
assert.ok(vm.run(`buffer.__proto__ === Buffer.prototype`));
assert.ok(vm.run(`buffer`).__proto__ === Buffer.prototype);
assert.ok(vm.run(`buffer.slice(0, 1) instanceof Buffer`));
assert.ok(vm.run(`buffer.slice(0, 1)`) instanceof Buffer);

CLI

Before you can use vm2 in command line, install it globally with npm install vm2 -g.

$ vm2 ./script.js

Known Issues

  • It is not possible to define class that extends proxied class.

Deployment

  1. Update the CHANGELOG
  2. Update the package.json version number
  3. Commit the changes
  4. Run npm publish

Sponsors

Integromat