CVE-2023-37466 - VM2 - Sandbox Escape Vulnerability

[chancekbarkley]

CVE-2023-37466 - VM2 - Sandbox Escape Vulnerability

The VM2 Package is vulnerable to Sandbox Escape. As of this week, the VM2 Project has been discontinued.

CVE-2023-37466

[sfc-gh-dszmolka]

hello and thank you for submitting this issue ! seems to come from one of urllib's dependencies proxy-agent which in turn ends up depending on vm2 due to pac-proxy-agent -> degenerator

there seems to be an Issue submitted over there too about the same concern: TooTallNate/proxy-agents#218

we'll see what we can do on our end (besides upgrading to urllib v3 which doesn't seem to require vm2 at all)

[Kszemi]

Are there any predictions on when will the problem be solved and new npm version released?

[sfc-gh-dszmolka]

a great question. for the proxy-agents issue where the Snowflake driver inherits this vulnerability from, I cannot give any estimations but hopefully the folks over there will fix it soon. for our own driver at this moment, I also cannot give an estimation for the fix since it's very fresh, but will keep this Issue updated with new information as soon as they are available.

in my own personal opinion it is unlikely the fix makes it into the July driver release, given the release date is already close. i can still be wrong though!

on the same note I would very much like to mention a robbkidd's comment from over the proxy-agents Issue, which comment I found very useful and helpful to determine the actual impact the vulnerability currently seem to have. it's linked just above, but quoting also here so people coming here could also find it:

robbkidd commented yesterday
❓Is my understanding of the exposure to the vm2 vulnerability to users of proxy-agent as of v6.2.2 correct? ❓

• JS runtime with proxy-agent loaded will have pac-proxy-agent loaded and therefore vm2.
• HTTP_PROXY/HTTPS_PROXY are not set: ✅
  the pac-proxy-agent codepaths are not exercised and therefore vm2 is never used.
• HTTP_PROXY/HTTPS_PROXY are set, but values do not start with pac*: ✅
  the pac-proxy-agent codepaths are not exercised and therefore vm2 is never used.
• HTTP_PROXY/HTTPS_PROXY are set to a URL starting with pac* pointing to a proxy auto-config file: 🤔
  pac-proxy-agent is exercised, vm2 is used, and the code injection would have to be in the contents of the PAC file retrieved?

to me, the above means that if you're not using a HTTP_PROXY/HTTPS_PROXY with a URL starting with pac* and thus a proxy auto-config file, you're not exposed to this vulnerability.
regardless, it still needs to be fixed, just thought this could be a useful information to share.

[sfc-gh-dszmolka]

quick update: upstream issue in proxy-agent is fixed couple minutes ago (proxy-agent@6.3.0) but our underlying urllib@2.40.0 sticks with v5 of the library so even if it's fixed upstream, we still need to fix it here. We're working on it and will provide updates.

[tony-snoop]

FYI: Upvoting this issue as this vulnerability is also being flagged on our end by snyk:

snowflake-sdk@1.6.22 › urllib@2.40.0 › proxy-agent@5.0.0 › pac-proxy-agent@5.0.0 › pac-resolver@5.0.1 › degenerator@3.0.4 › vm2@3.9.19

(that being said - I could upgrade to the lastest 1.6.23 version)

[WikiRik]

(that being said - I could upgrade to the lastest 1.6.23 version)

1.6.23 does not fix this issue, but they're working on it so the next release will

[sfc-gh-dszmolka]

about the release timeline - please see this comment. freeze for this month's release is quite close so really doubt it'll make it into this month's release.
same comment for the possible impacted scenarios. thank you all for bearing with us while this is sorted !

[sfc-gh-dszmolka]

hi folks I have some update.

so the vulnerability has been eliminated from snowflake-sdk with #575 which is merged now.

this is a short-term stopgap hotfix, and it works by excluding the vm2 dependency from the project. It completely eliminates the vulnerability (and comes with a possible side-effect if you happen to use the vm2 vulnerable code path in your application: having pac* proxy definition in your HTTP_PROXY / HTTPS_PROXY envvars, that is.)

this approach uses the overrides directive, which due to how npm works (if you use that), might need a bit of further explanation, see in below comment which I wanted to separate from this 'update on vm2 vulnerability' comment

change is available right now in the main branch, and will be released with the upcoming next version of the driver towards end of July.

on the long-term for the proper approach, we'll replace the old urllib v2 dependency, which (amongst other woes) will also eliminate vm2 completely, which is not in scope for this Issue which aims to address the vm2 vulnerability, which it did.

[sfc-gh-dszmolka]

and now, overrides.

delicacies of npm vs overrides:
this is due to how npm works, see details in npm/cli#4517. It's an undocumented behaviour, causing quite some headache. Basically, the overrides directive only works in the root package.json of your project with npm. Which is, in context of snowflake-sdk , totally fine if you for example check it out from GitHub then do a npm install over the checked-out code; then it is the root package.json over which you do the npm install and overrides works just fine.

But if you don't do that and have a project of which snowflake-sdk is just a part of (probably), then due to the aforementioned npm behaviour, the overrides defined in snowflake-sdk package.json simply won't work.

How to make it work then ? demonstrating on one of the overridden packages, semver, and apologies from everyone to whom this is a trivial information:

1. install snowflake-sdk from npm
2. check overrides in snowflake-sdk package.json:

  "overrides": {
    "@azure/storage-blob": {
      "node-fetch": "^3.2.10"
    },
    "semver": "^7.5.2",
    "vm2": "../_EXCLUDED_"
  },

However, semver still not overridden despite the override:

# npm ls semver
node@ /node
`-- snowflake-sdk@1.6.23 (git+ssh://git@github.com/snowflakedb/snowflake-connector-nodejs.git#4cacb2ca2d0258c38083f92874412e2e7f3c681f)
  +-- jsonwebtoken@9.0.1
  | `-- semver@7.5.4
  `-- urllib@2.40.0
    `-- default-user-agent@1.0.0
      `-- os-name@1.0.3
        `-- win-release@1.1.1
          `-- semver@5.7.2.  <<< this should be major version 7 due to the override

3. This is because of the aforementioned npm behaviour. It only works in the project root package.json which is this after the npm install (i already had log-timestamp preinstalled):

# cat package.json 
{
  "dependencies": {
    "log-timestamp": "^0.3.0",
    "snowflake-sdk": "github:snowflakedb/snowflake-connector-nodejs"
  }
}

No overrides == no overrides.
4. edit the project root package json to have the overrides from snowflake-sdk:

# cat package.json 
{
  "dependencies": {
    "log-timestamp": "^0.3.0",
    "snowflake-sdk": "github:snowflakedb/snowflake-connector-nodejs"
  },
  "overrides": {
    "@azure/storage-blob": {
      "node-fetch": "^3.2.10"
    },
    "semver": "^7.5.2",
    "vm2": "../_EXCLUDED_"
  }
}

5. run npm update snowflake-sdk in the project root to update the package, which will now consider the overrides due to them being in the project root package.json
6. recheck semver

# npm ls semver
node@ /node
`-- snowflake-sdk@1.6.23 (git+ssh://git@github.com/snowflakedb/snowflake-connector-nodejs.git#4cacb2ca2d0258c38083f92874412e2e7f3c681f)
  +-- jsonwebtoken@9.0.1
  | `-- semver@7.5.4 overridden.   <<< override now took effect
  `-- urllib@2.40.0
    `-- default-user-agent@1.0.0
      `-- os-name@1.0.3
        `-- win-release@1.1.1
          `-- semver@7.5.4 deduped.  <<< override now took effect

[ericjperry]

@sfc-gh-dszmolka thank you for the updates and the quick action on this issue. Unfortunately our attempt to mirror this change in our own repository (using the _EXCLUDED_ override in our own package.json, vm2 is only present as a transitive dependency of the snowflake sdk) has been unsuccessful due (we believe) to this existing bug with npm ci regarding overrides.

Do you have any timeline for the urllib/long term changes mentioned in your comments? Any advice on making these changes play nicely with npm ci?

Thanks!

[sfc-gh-dszmolka]

no, sadly I couldn't make this work with npm ci either yet @ericjperry , and I assume you already are through all the things people tried over at npm/cli#4942.
if someone else stumbles upon this and has a good way of solving Missing: vm2@ from lock file with npm ci , please do share.

for the long term fix timelines, at this very moment of writing I cannot comment on any timeline but will do as soon as I'm able to. What I can tell though, the long term fix for challenges introduced by urllib v2 has great visibility and is very high priority in this project.

edit: expected to be completed by Q3 end, but again: high priority and we aim to do it sooner. I'll also raise a separate issue in the repo to keep track of the efforts.

[deej-split]

I'm happy to see a fix is being worked on for this. Thank you. I'm curious when your Q3 is @sfc-gh-dszmolka .

[sfc-gh-dszmolka]

@deej-split for long term solution, you can also follow #590 Our Q3 ends with October 2023. No, this doesn't mean we aim for the long-term solution to be deployed on 31 October :)

this one will be closed down upon release of the next Snowflake Node.JS connector, as it's been resolved with a short-term fix.

[younisshah]

While we are waiting for the next release to fix this vulnerability, we did a poor man's vm2 exclusion:

We used npm-dependency-exclusion

1. In package.json, add this:

"exclusions": {
   "vm2": "any"
 }

2. Install your deps:
   npm install --production
3. Remove vm2 from package-lock.json by running:
   npx npm-dependency-exclusion
4. Finally remove vm2 from node_modules:
   rm -rf node_modules/vm2
5. Run a snyk scan.

Snyk scan passed.

This unblocked our deployment pipelines. Let me know if this works for anyone.

[sfc-gh-dszmolka]

PR is released as part of the latest Snowflake Node.JS driver version 1.7.0. Closing this issue.

[sfc-gh-dszmolka]

Releng team hit a bump in the release process which will be continued on Monday as expected. Reopening the issue and will only close when artifact confirmed to published to npm. Apologies for the inconvenience.

[sfc-gh-dszmolka]

PR is released as part of the latest Snowflake Node.JS driver version 1.7.0, for real this time :) Visible on npm too. Closing this issue and thank you for bearing with us !

note: as mentioned in an above comment, this is a workaround , a stopgap hotfix to address the security vulnerability.
can be implemented with the override as explained above, or alternatively with npm-dependency-exclusion per @younisshah comment.

for a long term proper solution we'll replace urllib v2, and there's a separate issue open for that which you can follow if you're interested (#590 )

[ericjperry]

Thanks again for all the information and updates @sfc-gh-dszmolka. I also wanted to close the loop on my earlier question with npm ci and say that @younisshah's comment got me sorted out. I followed a slightly modified set of steps:

1. In the package.json added:

"exclusions": {
   "vm2": "any"
 }

2. Manually removed all references to vm2 from package-lock.json.
3. rm -rf node_modules
4. npm ci
5. Validated that vm2 was not installed.
6. Validated successful snyk test.

[sfc-gh-dszmolka]

update: apparently urllib v2 had a new release 2.41.0 which removed the vm2 dependency completely (well, moved it to peer-dependencies and provides it as dev-dependency)
a fresh reinstall of snowflake-sdk should automatically install urllib v2.41.0 which does not depend on the vulnerable vm2 module, thus should eliminate the need for workarounds.

edit: due to above circumstances, the short-term workaround is not necessary anymore, so we reverted it (#614), thus the exclusion won't be part of the next release and going forward.

[deanesmith]

Thank you for the update @sfc-gh-dszmolka. Will there be a patch version bump soon that will include this?

[sfc-gh-dszmolka]

Yes, since the PR is already merged, it will be part of the next release. Normally, we release client drivers in the second half of the month, so this should be out by end of August.

[sfc-gh-dszmolka]

the urllib version bump (2.41.0) and exclusion workaround revert is now released with snowflake-sdk version 1.8.0