robbkidd
commented
1 year ago We're keeping an eye on upstream for a fix for the moment.
In the meantime, here's some information about Honeycomb's use of vm2:
- vm2 comes in to libhoney through superagent-proxy, used for transmitting data when behind an HTTP proxy
- libhoney -> superagent-proxy -> pac-proxy-agent-> (some more stuff) -> vm2
- superagent-proxy is only loaded into the JS runtime environment by libhoney if you have configured libhoney to send data to Honeycomb through an HTTP proxy, generally through setting some conventional HTTP_PROXY/HTTPS_PROXY environment variables
- superagent-proxy only engages the code path that uses vm2 if you are supplying proxy connection details as a URL to a proxy auto-config (PAC) file, for example
pac+http://www.example.com/proxy.pac
What's This Mean For A Libhoney User?
(according to our current understanding, confirmed upstream)
- No HTTP_PROXY or HTTPS_PROXY set for your Node services using libhoney: ✅
- vulnerable vm2 library is not loaded in your application runtime by libhoney
- HTTP_PROXY/HTTPS_PROXY are set, but do not use a proxy auto-config URL: 🆗
- vulnerable vm2 library may be loaded, but is not in the execution path of libhoney operations.
- HTTP_PROXY/HTTPS_PROXY are set to use a proxy auto-config URL: ❓
- exposure to the vulnerability in vm2 depends on the contents of the PAC file served by that URL endpoint
Versions
Description
In vm2 for versions up to 3.9.19, Promise handler sanitization can be bypassed, allowing attackers to escape the sandbox and run arbitrary code. The vm2 project alerts to the existence of critical security issues and claims to have been discontinued, therefore recommending replacing vm2 with isolated-vm.