Security Issues

[erhathaway]

Describe the issue you're having

Multiple security issues exist

What OS version are you using

Irrelevant b/c I ran a security scanner on the dependencies. Not related to OS

What device are you using

Irrelevant b/c I ran a security scanner on the dependencies. Not related to device.

Findings:

Using snyk on the master branch exposed multiple security issues:

Tested 948 dependencies for known issues, found 9 issues, 3853 vulnerable paths.

Issues to fix by upgrading:

  Upgrade react-native@0.61.5 to react-native@0.62.0 to fix
  ✗ Prototype Pollution [Medium Severity][https://snyk.io/vuln/SNYK-JS-YARGSPARSER-560381] in yargs-parser@7.0.0
    introduced by react-native@0.61.5 > @react-native-community/cli@3.0.4 > metro@0.56.3 > yargs@9.0.1 > yargs-parser@7.0.0 and 5 other path(s)

Patchable issues:

  Patch available for lodash@4.17.15
  ✗ Prototype Pollution [Medium Severity][https://snyk.io/vuln/SNYK-JS-LODASH-567746] in lodash@4.17.15
    introduced by react-native-vector-icons@6.6.0 > lodash@4.17.15 and 1329 other path(s)

  Patch available for semver@2.3.2
  ✗ Regular Expression Denial of Service (ReDoS) [Medium Severity][https://snyk.io/vuln/npm:semver:20150403] in semver@2.3.2
    introduced by react-native-level-fs@3.0.1 > levelup@0.18.6 > semver@2.3.2

Issues with no direct upgrade or patch:
  ✗ Prototype Pollution [Medium Severity][https://snyk.io/vuln/SNYK-JS-HAPIHOEK-548452] in @hapi/hoek@8.5.0
    introduced by react-native@0.61.5 > @react-native-community/cli@3.0.4 > @hapi/joi@15.1.1 > @hapi/hoek@8.5.0 and 1 other path(s)
  This issue was fixed in versions: 8.5.1, 9.0.3
  ✗ Information Exposure [Low Severity][https://snyk.io/vuln/SNYK-JS-KINDOF-537849] in kind-of@6.0.2
    introduced by react-native@0.61.5 > @react-native-community/cli@3.0.4 > metro-core@0.56.3 > jest-haste-map@24.9.0 > micromatch@3.1.10 > kind-of@6.0.2 and 2419 other path(s)
  This issue was fixed in versions: 6.0.3
  ✗ Remote Code Execution (RCE) [High Severity][https://snyk.io/vuln/SNYK-JS-LOGKITTY-568763] in logkitty@0.6.1
    introduced by react-native@0.61.5 > @react-native-community/cli-platform-android@3.0.3 > logkitty@0.6.1
  No upgrade or patch available
  ✗ Prototype Pollution [Medium Severity][https://snyk.io/vuln/SNYK-JS-MINIMIST-559764] in minimist@0.0.8
    introduced by react-native@0.61.5 > @react-native-community/cli@3.0.4 > minimist@1.2.0 and 87 other path(s)
  This issue was fixed in versions: 0.2.1, 1.2.3
  ✗ Uninitialized Memory Exposure [Medium Severity][https://snyk.io/vuln/npm:bl:20160119] in bl@0.8.2
    introduced by react-native-level-fs@3.0.1 > levelup@0.18.6 > bl@0.8.2
  This issue was fixed in versions: 0.9.5, 1.0.1
  ✗ Denial of Service (DoS) [Medium Severity][https://snyk.io/vuln/npm:mem:20180117] in mem@1.1.0
    introduced by react-native@0.61.5 > @react-native-community/cli@3.0.4 > metro@0.56.3 > yargs@9.0.1 > os-locale@2.1.0 > mem@1.1.0 and 3 other path(s)
  This issue was fixed in versions: 4.0.0

Suggested Actions

I highly suggest the team integrate security scanners into the CI / build pipeline. I was also unable to find the build pipeline. Post-install scripts are a common attack vector. These should also be disabled for all production builds.

[perry-mitchell]

I hear you. The build process is the worst on mobile out of our apps, and could do with an improved configuration and update procedure.

The issue I see is primarily one of effort - I don't have the time to perform regular maintenance for updates to React Native (the main culprit). The prototype pollution stuff will never fully disappear so I'd worry less about that. Not all vulnerabilities present in package reporting tools are relevant to the application itself. Agreed on the postinstall point, though this too is difficult to avoid as it requires very thorough grooming of packages that don't require postinstall scripts. Right now React-native needs several to be configured correctly.

[maciek134]

The prototype pollution stuff will never fully disappear so I'd worry less about that.

This is a dangerous thing to say, it should disappear. Prototype pollution makes it so a bug in one package can spread to the whole codebase, so it's something I'd rather not see in a security/privacy focused app.

(how is it that in 2020 people still use lodash is beyond my comprehension, and it's usually lodash that's the problem)

I can provide a PR for this (and re-do it periodically after new RN drops if you don't have the time), but sadly I don't see any tests in this project, so making sure everything works may take some time. As for postinstall (or any scripts at all) when you can't disable them: I'd suggest auditing any that are there at the moment, pinning packages that have them and re-audit on each upgrade.