Critical vm2 sandbox escape flaw uncovered, patch ASAP! (CVE-2022-36067)
Oxeye researchers discovered a severe vm2 vulnerability (CVE-2022-36067) that has received the maximum CVSS score of 10.0. Called SandBreak, this new vulnerability requires R&D leaders, AppSec engineers, and security professionals to ensure they immediately patch the vm2 sandbox if they use it in their applications.
vm2 Javascript sandbox library
vm2 is the most popular Javascript sandbox library, with around 17.5 million monthly downloads. It provides a commonly used software testing framework capable of running untrusted code synchronously in a single process.
It is one of the more popular testing environments in use by millions of developers because it allows complete control over the sandbox’s console output with the ability to limit access to select built-in modules or securely call methods and exchange data between sandboxes.
The Oxeye research team found a critical sandbox escape vulnerability that leads to remote code execution in vm2. The vulnerability was disclosed to the project owners and was rapidly patched in version 3.9.11. GitHub issued advisory CVE-2022-36067 for this vulnerability and gave it a CVSS score of 10, putting users on alert.
“We were surprised when we discovered this vulnerability, as the vm2 sandbox module is extremely popular, and sandboxes by their definition should be safe. At the same time, we also felt glad that we found it, as we could then help secure it and give back to the community. After all, we are not only security researchers and enthusiasts but also developers who use open source components,” Dean Agron, CEO of Oxeye, told Help Net Security.
What is the potential impact of CVE-2022-36067?
A threat actor who exploits this vulnerability will be able to bypass the vm2 sandbox environment and run shell commands on the machine hosting it. Sandboxes serve different purposes in modern applications, such as examining attached files in email servers, providing an additional security layer in web browsers, or isolating actively running applications in certain operating systems.
Given the nature of the use cases for sandboxes, it’s clear that the vm2 vulnerability can have dire consequences for applications that use vm2 without patching. The fact that this vulnerability has the maximum CVSS score, and is extremely popular, means its potential impact is widespread and critical.
“Our usual approach when evaluating a given software’s security is first to analyze the previous security lapses discovered in the same software. This helps us better grasp the available attack surface and may also lead to low-hanging bugs stemming from incomplete fixes. It also helps us come up with techniques to bypass the implemented fixes. 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,” said Gal Goldshtein, Senior Security Researcher at Oxeye.
Yuval Ostrovsky, Architect at Oxeye, added that “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.”