A critical (CVSS 10) vulnerability in a widely used open source library, vm2, has forced downstream updates in widely used software including from IBM and Red Hat – security teams should be keeping a watchful eye out.
CVE-2023-32314 is a sandbox escape vulnerability in vm2, a JavaScript sandbox that, despite having little name recognition outside the developer community, was downloaded over 23 million times in May 2023.
Exploitation of the latest vm2 vulnerability – reported by Takeshi Kaneko of GMO Cybersecurity by Ierae, Inc. – lets a successful attacker gain remote code execution (RCE) rights on the host running the sandbox.
No privileges and no user interaction are required for the exploit.
New vm2 vulnerability is 4th CVSS 10 bug in weeks
CVE-2023-32314 affects vm2 versions up to 3.9.17.
Both an exploit and a patch have been released.
CVE-2023-32314 is the fifth highly critical sandbox escape vm2 vulnerability in recent months – and the fourth to get a CVSS score of 10, joining CVE-2022-36067 (CVSS 10), CVE-2023-29017 (CVSS 9.8), CVE-2023-29199 (CVSS 10), and CVE-2023-30547 (CVSS 10).
With much software involving so many open source building blocks – many of them maintained (where they are maintained at all) by tiny and under-resourced teams, the risk of severe vulnerabilities making their way into the downstream builds of other software that fails to update these open source building blocks is a very live problem for security teams.
See also: Global CISOs, White House, agree 10-point open source security plan
As Sophos has earlier noted, a huge amount of back-end server logic in cloud-based services is coded in JavaScript, typically using node.js: “vm2 aims to provide the same sort of sandboxing protection for full-blown server-based apps as your browser provides for JavaScript in web pages.”
(Red Hat was among those that patched recently, pushing a fix for its Advanced Cluster Management for Kubernetes that updates vm2 to a fixed version. IBM pushed fixes for its IBM App Connect Enterprise.)
Speaking to The Stack earlier this week about an unrelated story (an apparent Gigabyte motherboard backdoor) firmware and supply chain security specialist John Loucaides from Eclypsium noted that this kind of upstream software vulnerability was an increasing risk that reminded him of the kind of damage that could be done by things like the Heartbleed bug back in 2014 in the popular OpenSSL cryptographic software library.
He said that Eclypsium regularly saw vulnerable packages being baked into software from OEMs: “OEMs and ODMs use reference code or some embedded module that gets shipped inside of a system… The most common thing that I see is that there is an update to that thing and they don't have it. It's actually very hard to discover this [vulnerable upstream component of a software product], because you get stuff compiled into other stuff and it's a pain. Even if you're good at it, you miss one…”
Speaking to The Stack last year, David A. Wheeler, director of open source supply chain security at the Linux Foundation, said: "We have an endemic problem of not enough people knowing how to develop secure software."
"...When you are a customer, what you see is, here's a product that solves a problem. When you are the developer, you see what's called your immediate dependencies... n many, many cases [your indirect dependencies are] mostly invisible. Yes, if you watch carefully, you can see debug information that will tell you, 'I'm downloading these 3,000 other things right now' but it's not at all unusual today, for example, if you start a web front-end application using something like React [to have] something like 700 direct and indirect dependencies for an empty React project."
