A critical vulnerability in vm2 may allow a remote attacker to escape the sandbox and execute arbitrary code on the host.

A highly popular JavaScript sandbox library with more than 16 million monthly downloads, vm2 supports the execution of untrusted code synchronously in a single process.

In August 2022, security researchers with Oxeye discovered CVE-2022-36067, a critical-severity defect in vm2 assessed with a CVSS score of 10 and which should put all vm2 users on alert, due to its potential widespread impact.

The root cause of the vulnerability, which Oxeye’s researchers have named SandBreak, resides in the way vm2 maintainers implemented a Node.js feature that allows them to customize the call stack of errors in the software testing framework.

“While reviewing the previous bugs disclosed to the vm2 maintainers, we noticed an interesting technique: the bug reporter abused the error mechanism in Node.js to escape the sandbox,” Oxeye senior security researcher Gal Goldshtein said.

When an error occurs, Node.js calls a specific method and provides it with an array of ‘CallSite’ objects as arguments. Some of the CallSite objects, the researchers explain, may return objects created outside the sandbox.

An attacker controlling one of the returned objects may “access Node’s global objects and execute arbitrary system commands from there”, Oxeye says.

To mitigate the risk, the vm2 implementation wrapped objects and the called method (the prepareStackTrace function of the Error object) in a manner that prevented users from overriding it.

However, because they did not wrap all specific methods, an attacker could provide their own implementation of the prepareStackTrace method and escape the sandbox.

Oxeye’s researchers were also able to override the global Error object with their own implementation that also included a custom prepareStackTrace function. When called, it would find a CallSite object outside the sandbox, allowing for the execution of arbitrary code on host.

The SandBreak vulnerability was addressed with the release of vm2 version 3.9.11 on August 28, but technical details on the bug have not been provided until now. Oxeye plans on publishing a technical blog post later this week.

Oxeye calls for AppSec engineers, R&D leaders, and security professionals to make sure that all vm2 sandbox instances within their environments are patched.

“Although sandboxes are meant to run untrusted code within your application, you shouldn’t automatically assume that they are safe. If the use of a sandbox is unavoidable, it is recommended to separate the logical sensitive part of your application from the microservice that runs the sandbox code so if a threat actor successfully breaks out from the sandbox, the attack surface is limited to the isolated microservice,” Oxeye architect Yuval Ostrovsky said.

By Ionut Arghire on Mon, 10 Oct 2022 11:05:45 +0000
Original link