Critical VM2 flaw lets attackers run code outside the sandbox

Malicious code running in a sandbox

Researchers are warning of a critical remote code execution flaw in ‘vm2’, a JavaScript sandbox library downloaded over 16 million times per month via the NPM package repository.

The vm2 vulnerability is tracked as CVE-2022-36067 and received a severity rating of 10.0, the maximum score in the CVSS system, as it could allow attackers to escape the sandbox environment and run commands on a host system.

Sandboxes are meant to be an isolated environment that is walled off from the rest of the operating system. However, as developers commonly use sandboxes to run or test potentially unsafe code, the ability to “escape” from this confined environment and execute code on the host is a massive security problem.

Escaping the sandbox

Security researchers at Oxeye have found a clever way to customize the call stack of an error that occurs in VM2 to generate “CallSite” objects created outside the sandbox and use them to access Node’s global objects and execute commands.

While the library’s authors attempted to mitigate this possibility in the past, Oxeye’s researchers found a way to bypass this mitigation mechanism by using a custom implementation of the “prepareStackTrace” method.

“The reporter’s POC bypassed the logic above since vm2 missed wrapping specific methods related to the “WeakMap” JavaScript built-in type,” the researchers explain in their report. 

“This allowed the attacker to provide their own implementation of “prepareStackTrace,” then trigger an error, and escape the sandbox.”

The sandbox escape processSandbox escape process

The analysts found that it’s also possible to override the global Error object with a custom object that implements the “prepareStackTrace” function, again accessing “CallSite” objects created outside the sandbox and running commands in the current process.

Overriding the Error object and generating an errorOverriding the Error object and accessing CallSite objects (Oxeye)

Update as soon as possible

Oxeye’s research team discovered this critical problem on August 16, 2022, and reported it to the VM2 team a couple of days later, who confirmed they had launched an investigation.

Eventually, the authors of the popular library released version 3.9.11 on August 28, 2022, which addressed the sandbox escape and code execution problems.

Software developers are urged to update to the latest VM2 version and replace older releases in their projects as soon as possible.

For end users, it is important to note that it could take a while before virtualization software tools relying on VM2 apply the available security update.

As we saw with Log4Shell, a critical security problem in a widely deployed open-source library may persist for extended periods without the impacted users even knowing they’re vulnerable due to the obscurity in the supply chain.

If you use a sandbox solution, check if it relies on VM2 and whether it’s using the latest version.


Related posts

Chick-fil-A investigates reports of hacked customer accounts

Sarah Henriquez

T-Mobile discloses second data breach since the start of 2023

Sarah Henriquez

Neopets data breach exposes personal data of 69 million members

Sarah Henriquez

Leave a Comment