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 process
Sandbox escape process
(Oxeye)

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 error
Overriding 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 Articles:

New Ivanti RCE flaw may impact 16,000 exposed VPN gateways

Over 1,400 CrushFTP servers vulnerable to actively exploited bug

Maximum severity Flowmon bug has a public exploit, patch now

Hackers hijack OpenMetadata apps in Kubernetes cryptomining attacks

Palo Alto Networks fixes zero-day exploited to backdoor firewalls