Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Security issue: node's VM module doesn't prevent you from accessing the node stdlib #5

Closed
odino opened this issue Mar 4, 2017 · 5 comments

Comments

@odino
Copy link

@odino odino commented Mar 4, 2017

As simple as:

safeEval("this.constructor.constructor('return process')().exit()")

This should be mentioned in the readme, as the VM isn't so safe and people might instead think this prevents any kind of attack :)

Ref: patriksimek/vm2#59

@odino odino changed the title Securrity issue: node's VM module doesn't prevent you from accessing the node stdlib Security issue: node's VM module doesn't prevent you from accessing the node stdlib Mar 4, 2017
@phucluke

This comment has been minimized.

Copy link

@phucluke phucluke commented Dec 24, 2017

Hi the author,

The library is great. And is there any plan to fix this issue?

@hacksparrow

This comment has been minimized.

Copy link
Owner

@hacksparrow hacksparrow commented Jul 26, 2018

Fixed in 0.4.0.

@SuperOP535

This comment has been minimized.

Copy link

@SuperOP535 SuperOP535 commented Aug 15, 2018

this page doesn't say so https://www.npmjs.com/advisories/337

@odino

This comment has been minimized.

Copy link
Author

@odino odino commented Aug 15, 2018

Hey @SuperOP535 -- original reporter here :) I tried reproducing the issue with:

~ ᐅ cd /tmp 
/tmp ᐅ npm i safe-eval
npm WARN saveError ENOENT: no such file or directory, open '/tmp/package.json'
npm WARN enoent ENOENT: no such file or directory, open '/tmp/package.json'
npm WARN tmp No description
npm WARN tmp No repository field.
npm WARN tmp No README data
npm WARN tmp No license field.

+ safe-eval@0.4.1
added 1 package from 1 contributor and audited 2 packages in 1.854s
found 1 critical severity vulnerability
  run `npm audit fix` to fix them, or `npm audit` for details
/tmp ᐅ node
> safeEval = require('safe-eval')
[Function: safeEval]
> safeEval("this.constructor.constructor('return process')().exit()")
evalmachine.<anonymous>:11
  SAFE_EVAL_357108=this.constructor.constructor('return process')().exit()
                                    ^

TypeError: this.constructor.constructor is not a function
    at evalmachine.<anonymous>:11:37
    at Script.runInContext (vm.js:102:20)
    at Script.runInNewContext (vm.js:108:17)
    at Object.runInNewContext (vm.js:291:38)
    at safeEval (/tmp/node_modules/safe-eval/index.js:24:6)
    at repl:1:1
    at Script.runInThisContext (vm.js:91:20)
    at REPLServer.defaultEval (repl.js:317:29)
    at bound (domain.js:396:14)
    at REPLServer.runBound [as eval] (domain.js:409:12)

and it looks like safe-eval 0.4 fixes it. Not sure how the NPM advisories work, as it should probably be closed.

@cpcallen

This comment has been minimized.

Copy link

@cpcallen cpcallen commented Aug 24, 2018

Unfortunately the sanitisation in 7051474 is not sufficient to close the hole. I have sent a proof-of-concept to @hacksparrow by email.

The new exploit (like the one reported by @odino) is fragile, and there are many trivial ways to break it, but in general any access by the eval-ed code to any object from the caller's realm (e.g., if any object is passed in via context) will allow escaping the sandbox.

I would advise using vm2 instead. (Please note that I have not audited the code of vm2, so can make no representations about its correctness—but at least its author appears to fully understand the issues.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants
You can’t perform that action at this time.