Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CVE-2023-37466 - VM2 - Sandbox Escape Vulnerability #571

Closed
chancekbarkley opened this issue Jul 13, 2023 · 22 comments
Closed

CVE-2023-37466 - VM2 - Sandbox Escape Vulnerability #571

chancekbarkley opened this issue Jul 13, 2023 · 22 comments
Assignees
Labels
security vulnerability Security vulnerability detected by WhiteSource

Comments

@chancekbarkley
Copy link

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

@chancekbarkley chancekbarkley added the bug Something isn't working label Jul 13, 2023
@sfc-gh-dszmolka sfc-gh-dszmolka self-assigned this Jul 14, 2023
@sfc-gh-dszmolka sfc-gh-dszmolka added the status-triage Issue is under initial triage label Jul 14, 2023
@sfc-gh-dszmolka
Copy link
Collaborator

sfc-gh-dszmolka commented Jul 14, 2023

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)

@sfc-gh-dszmolka sfc-gh-dszmolka added security vulnerability Security vulnerability detected by WhiteSource status-in_progress Issue is worked on by the driver team and removed bug Something isn't working status-triage Issue is under initial triage labels Jul 14, 2023
@Kszemi
Copy link

Kszemi commented Jul 14, 2023

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

@sfc-gh-dszmolka
Copy link
Collaborator

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
Copy link
Collaborator

quick update: upstream issue in proxy-agent is fixed couple minutes ago ([email protected]) but our underlying [email protected] 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
Copy link

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

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

@WikiRik
Copy link

WikiRik commented Jul 18, 2023

(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
Copy link
Collaborator

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
Copy link
Collaborator

sfc-gh-dszmolka commented Jul 20, 2023

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
Copy link
Collaborator

sfc-gh-dszmolka commented Jul 20, 2023

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
`-- [email protected] (git+ssh://[email protected]/snowflakedb/snowflake-connector-nodejs.git#4cacb2ca2d0258c38083f92874412e2e7f3c681f)
  +-- [email protected]
  | `-- [email protected]
  `-- [email protected]
    `-- [email protected]
      `-- [email protected]
        `-- [email protected]
          `-- [email protected].  <<< this should be major version 7 due to the override
  1. 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_"
  }
}
  1. 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
  2. recheck semver
# npm ls semver
node@ /node
`-- [email protected] (git+ssh://[email protected]/snowflakedb/snowflake-connector-nodejs.git#4cacb2ca2d0258c38083f92874412e2e7f3c681f)
  +-- [email protected]
  | `-- [email protected] overridden.   <<< override now took effect
  `-- [email protected]
    `-- [email protected]
      `-- [email protected]
        `-- [email protected]
          `-- [email protected] deduped.  <<< override now took effect

@sfc-gh-dszmolka sfc-gh-dszmolka added status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. and removed status-in_progress Issue is worked on by the driver team labels Jul 20, 2023
@ericjperry
Copy link

@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
Copy link
Collaborator

sfc-gh-dszmolka commented Jul 21, 2023

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
Copy link

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
Copy link
Collaborator

@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
Copy link

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"
 }
  1. Install your deps:
    npm install --production
  2. Remove vm2 from package-lock.json by running:
    npx npm-dependency-exclusion
  3. Finally remove vm2 from node_modules:
    rm -rf node_modules/vm2
  4. Run a snyk scan.

Snyk scan passed.

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

@sfc-gh-dszmolka
Copy link
Collaborator

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

@sfc-gh-dszmolka sfc-gh-dszmolka removed the status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. label Jul 27, 2023
@sfc-gh-dszmolka
Copy link
Collaborator

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 sfc-gh-dszmolka added the status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. label Jul 28, 2023
@sfc-gh-dszmolka
Copy link
Collaborator

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 )

@sfc-gh-dszmolka sfc-gh-dszmolka removed the status-fixed_awaiting_release The issue has been fixed, its PR merged, and now awaiting the next release cycle of the connector. label Jul 28, 2023
@ericjperry
Copy link

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"
 }
  1. Manually removed all references to vm2 from package-lock.json.
  2. rm -rf node_modules
  3. npm ci
  4. Validated that vm2 was not installed.
  5. Validated successful snyk test.

@sfc-gh-dszmolka
Copy link
Collaborator

sfc-gh-dszmolka commented Aug 9, 2023

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
Copy link

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

@sfc-gh-dszmolka
Copy link
Collaborator

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
Copy link
Collaborator

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
security vulnerability Security vulnerability detected by WhiteSource
Projects
None yet
Development

No branches or pull requests

10 participants