vm2 is still in 3.9.17, safe version is >=3.9.18

[Grohden]

Steps to Reproduce

1. Install latest 8.0.2
2. yarn why vm2 (reports 3.9.17)
3. follow dep chain, at the end is react-native-code-push

Expected Behavior

What you expected to happen?

That the dependency is updated

Actual Behavior

What actually happens?

Dependency with security issues is not updated

Reproducible Demo

Install latest 8.0.2

and check the dependency chain

Environment

• react-native-code-push version: 8.0.2
• react-native version: yes
• iOS/Android/Windows version: yes
• Does this reproduce on a debug build or release build? yes
• Does this reproduce on a simulator, or only on a physical device? yes

maybe related PRs #2519 #2517
maybe related issue #2489

[latobibor]

I would also add that the react-native community is lagging behind with updating to versions 0.70+ so it would be gold to update vm2 for a couple of older main versions (like 7.1.0).

[Grohden]

Oh, just some infos I've discovered :D

We added resolution for >=3.9.18, however the nice thing is that it just changes the issue. The vm2 ib is deprecated

and the latest version simply doesn't have solutions for the security issues, thank you JS community 🙏

Think what can be explored bumping one of the chain dependencies of codepush

[latobibor]

Is there any way to tag the contributors to look for a replacement for this subtree of the dependency chain? One does not simply walk around with a wontfix critical vulnerability in town.

Oh, upon investigating it, I have found out that the dependencty is part of codepush-testing-framework-plugins. But why does the testing framework end up in production code? If the testing framework would not end up in the final package this moot security warning will disappear from our radar. (It must be a moot security vulnerability as that code should not make into the final bundle, is that assumption correct?)

[trcoffman]

@latobibor the chain of dependencies that leads to vm2 being present in the app is react-native-code-push -> code-push -> superagent-proxy -> proxy-agent -> pac-proxy-agent -> pac-resolver -> degenerator

It appears to be used to execute a PAC (Proxy Auto Configuration) file.

[latobibor]

Thank you @trcoffman ! It seems I was optimistic. Indeed it is right in the middle of production code:
https://github.com/microsoft/code-push/blob/bf209665ed0e80bfacdc78df5576d852c82f8190/src/utils/request-manager.ts#L5C1-L5C1

superagent-proxy is used above in RequestManager. There is some movement in that package: TooTallNate/superagent-proxy#48

I hope the maintainer is still available to approve the PRs.

[trcoffman]

Does code-push set up superagent to adopt OS proxy configurations automatically? I'm trying to determine if this is actually exploitable and if apps running react-native-code-push are vulnerable to an RCE via PAC files.

[trcoffman]

From my reading of the code in react-native-code-push & code-push packages, I don't think that vm2 is exploitable in a react-native app using react-native-code-push.

[trcoffman]

@latobibor, I think that this vm2 vulnerability only poses a threat for the deprecated code-push-cli package which was replaced by appcenter-cli years ago.

If you were to run code-push-cli while having HTTP_PROXY environment variable set to a URL pointing to a malicious PAC file, that PAC file could escape the vm2 sandbox and achieve remote code execution inside the code-push-cli process.

Given that code-push-cli has been discontinued for years, it should be removed from the code-push repo and then vm2 would no longer need to be in the dependency tree of react-native-code-push which doesn't even use the parts of code-push that depend on vm2

[TheKohan]

Any plans on fixing this issue ? or any workarounds that can satisfy my SNYK ? 😄

[Dror-Bar]

Here is the vulnerability tree:

vm2  *
Severity: critical
vm2 Sandbox Escape vulnerability - https://github.com/advisories/GHSA-cchq-frgv-rjh5
vm2 Sandbox Escape vulnerability - https://github.com/advisories/GHSA-g644-9gfx-q4q4
fix available via `npm audit fix --force`
Will install [email protected], which is a breaking change
node_modules/vm2
  degenerator  3.0.0 - 4.0.4
  Depends on vulnerable versions of vm2
  node_modules/degenerator
    pac-resolver  5.0.0 - 6.0.2
    Depends on vulnerable versions of degenerator
    node_modules/pac-resolver
      pac-proxy-agent  5.0.0 - 6.0.4
      Depends on vulnerable versions of pac-resolver
      node_modules/pac-proxy-agent
        proxy-agent  5.0.0 - 6.2.2
        Depends on vulnerable versions of pac-proxy-agent
        node_modules/proxy-agent
          superagent-proxy  >=3.0.0
          Depends on vulnerable versions of proxy-agent
          node_modules/superagent-proxy
            code-push  >=4.0.5
            Depends on vulnerable versions of superagent-proxy
            node_modules/code-push
              react-native-code-push  >=7.0.3
              Depends on vulnerable versions of code-push
              node_modules/react-native-code-push

I was able to fix this by simply forcing a higher version of degenerator - currently it is 5.0.1.
Add the following to your package.json:

"overrides": {
   "degenerator": "https://registry.npmjs.org/degenerator/-/degenerator-5.0.1.tgz"
 }

And run npm install again

[latobibor]

If vm2 does not do anything in production anyways, I think it can be a simple fix. Also maybe this can be a great PR.

[adamivancza]

this issue should be reopened as it is not solved

[MikhailSuendukov]

Hi everyone! Could you please confirm what this issue still persist on latest version (8.2.1)?