Sandbreak vm2 Flaw is a 10 But Exposes Vulnerability of Sandboxes
As vulnerabilities go, the Sandbreak vm2 flaw is as potentially as severe as it gets, snagging a 10.0 CVSS score.
The bug, CVE-2022-36067, should be immediately patched if it’s used with applications, according to the Oxeye researchers who discovered the vulnerability. A threat actor who exploited the remote control execution (RCE) vulnerability could “bypass the vm2 sandbox environment and run shell commands on the machine hosting the sandbox,” Oxeye researchers wrote in a blog post. They noted that “given the nature of the use cases for sandboxes, it’s clear that the vm2 vulnerability can have dire consequences for applications that use it.”
Given the popularity of the vm2 library and the severity of the flaw, “its potential impact is widespread and critical,” the researchers said.
“Many of the use cases for vm2 are regarding isolation. It’s rarely a good day when an isolation tool no longer can do its job,” said Miclain Keffeler, cybersecurity consultant at nVisium. “The scope of CVE-2022-36067 certainly lives up to its rating, which marks a high risk for countless organizations.”
Other security experts agreed. “Sandboxes exist for multiple reasons and anything that would let an attacker break out of one is problematic. The vulnerability disclosed here justifies its high CVSS score given how widespread the library is and how severe a problem a sandbox break is in context,” said Mike Parkin, senior technical engineer at Vulcan Cyber.
Oxeye discovered the vulnerability on August 16, 2022, after researchers decided to explore what would happen if the trust put into sandboxes was compromised. “This thesis drove our explorations and eventually led us to discover the vm2 sandbox vulnerability,” the researchers said.
They started with a review of vm2’s previous security lapses to “better grasp the available attack surface and may also lead to low-hanging bugs stemming from incomplete fixes,” Oxeye wrote. That approach, they said, helped to “come up with techniques to bypass the implemented fixes.”
As they reviewed previous vm2 lapses, they “noticed an interesting technique: The bug reporter abused the error mechanism in Node.js to escape the sandbox,” according to the blog post. Node.js “allows the application developer to customize the call stack of an error that occurred in the application.”
Customizing the call stack can achieve this by implementing the “prepareStacktrace” method under the global “Error” object and can be used to customize the call stack so that when an error occurs “and the ‘stack’ property of the thrown error object is accessed, Node.js will call this method while providing it with a string representation of the error alongside an array of ‘CallSite’ objects as arguments,” researchers noted.
A method exposed by CallSite objects—each of which represents a different stack frame in an array—called “getThis” turned out to be the culprit behind “sandbox escapes as some of the ‘CallSite”’ objects may return objects created outside the sandbox when invoking the ‘getThis’ method.”
Keffeler pointed out that “while we often blame people for being our weakest link, this highlights that there are times when this is not the case; in fact, this is as bad or worse than a people-induced flaw, depending on the use case.”
Oxeye researchers cautioned that while sandboxes are designed to run untrusted within applications, organizations “shouldn’t automatically assume they are safe.” If using a sandbox, they recommend separating the “logical sensitive part” of the 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.”
In addition, “avoid using a sandbox that relies on a dynamic programming language such as JavaScript when possible,” they wrote. “The dynamic nature of the language widens the attack surface for a potential attacker, making defending against such attacks much harder.”
“Fortunately, the developer addressed it quickly with a patch and there’s no indication yet that the vulnerability was exploited in the wild,” Parkin noted, but urged “anyone who leverages the vm2 library to patch sooner rather than later.”
As the rate of high-impact findings increase “across the board, this CVE highlights the need for a mature patching process. It is more crucial than ever to stay vigilant in the AppSec space, focus on the ‘security onion’ as it should be—no one individual or security control will ever be enough,” said Keffeler. “Which is why we hope that those that cannot immediately patch have another mitigating control for this particularly critical CVE.”
Because “vulnerability researchers are more likely to look at the high-profile dependencies of your application, resulting in more frequent vulnerabilities within the dependency,” Oxeye said, “make sure to monitor your application dependencies frequently and upgrade their versions accordingly.”
