npm false positive CVEs

[thediveo]

More false positives turned up in the web UI part of my lxkns project.

ignore:
    # Barking up the wrong tree...
    - vulnerability: CVE-2009-4590 # php, not npm package
      package:
        type: npm
    - vulnerability: CVE-2009-4591 # sql engine, not npm package
      package:
        type: npm
    - vulnerability: CVE-2009-4592 # php, not npm package
      package:
        type: npm
    - vulnerability: CVE-2011-0220 # apfel bonjour, not npm package
      package:
        type: npm
    - vulnerability: CVE-2013-1779 # drupal, not npm package
      package:
        type: npm
    - vulnerability: CVE-2014-2980 # gnustep, not npm package
      package:
        type: npm
    - vulnerability: CVE-2017-18589 # rust, not npm package
      package:
        type: npm
    - vulnerability: CVE-2020-7663 # ruby, not npm package
      package:
        type: npm
    - vulnerability: CVE-2020-7753 # component/trim, not Trott/trim
      package:
        type: npm

[luhring]

Thanks @TheDiveO! Keep 'em coming.

[thediveo]

And another one, where the CVE origins can't get their act correctly and make another mess: a match of CVE-2015-5237 on google.golang.org/protobuf ... which actually is the golang version, where the CVE seems to refer to https://github.com/protocolbuffers/protobuf, see also the CVE reference to https://github.com/protocolbuffers/protobuf/issues/760 which is the C version, but not the Go implementation.

[westonsteimel]

And another one, where the CVE origins can't get their act correctly and make another mess: a match of CVE-2015-5237 on google.golang.org/protobuf ... which actually is the golang version, where the CVE seems to refer to https://github.com/protocolbuffers/protobuf, see also the CVE reference to protocolbuffers/protobuf#760 which is the C version, but not the Go implementation.

@luhring, one thing that might help for Go in particular would be to make use of the information coming from The Go Vulnerability Database and the corresponding go module x/vuln. In this case CVE-2015-5237 is already identified as a false positive there: https://github.com/golang/vuln/blob/f553aa4445846cef9869d51edc1da637ea30bb77/triaged-cve-list#L29

[thediveo]

Yet the false positives I reported here are mostly hitting the npm world, except for the lately mentioned protobuf-related Go mod false positive. I find it slightly worrysome that all ecosystems will/would need to maintain their own false positive "defense shields" to deflect the sometimes mediocre quality of NVD/* originating CVE information, where there seems to be a fondness of using "*" much too often and thus basically crying "wolf" all the time on world+dog.

[luhring]

And another one, where the CVE origins can't get their act correctly and make another mess: a match of CVE-2015-5237 on google.golang.org/protobuf ... which actually is the golang version, where the CVE seems to refer to https://github.com/protocolbuffers/protobuf, see also the CVE reference to protocolbuffers/protobuf#760 which is the C version, but not the Go implementation.

@luhring, one thing that might help for Go in particular would be to make use of the information coming from The Go Vulnerability Database and the corresponding go module x/vuln. In this case CVE-2015-5237 is already identified as a false positive there: https://github.com/golang/vuln/blob/f553aa4445846cef9869d51edc1da637ea30bb77/triaged-cve-list#L29

This is a great idea @westonsteimel, thanks! 👍

I find it slightly worrysome that all ecosystems will/would need to maintain their own false positive "defense shields"

I don't think I understand this fully, but I don't think it's necessary for all ecosystems to maintain the same kind of list. Here we have a problem, where the largest bottleneck is dirty data. Ideally, all ecosystem's vulnerability data is in good shape, but in practice it's not. Given that, I'd say consumers of this data (like Grype) should take any help they can get with opportunities to draw better conclusions from the data.

[thediveo]

What I'm referring here to is "cross polution", or in older terms, "clan liability", due to what you term "dirty data". As we won't have an ideal world, this means that a single act truely related to only one package in one ecosystem now causes lots of additional work in not only another, but even in several cases all other ecosystems. And that's because the database origin does sloppy work, causing lot of unnecessary work, while potentially easing its own work due to less work on initial due dilligence. This is unbelieveable more so as the running text of CVEs often correctly state the ecosystem or at least clearly hint at it. This sloppy upstream work then causes lots of friction and finally refusal with the real work horses, the developers; all this significantly reducing acceptance of security tools. And then we end up with security lip service.

[spiffcs]

@thediveo thanks again for filing this issue. We've done a ton of work recently regarding corrections in the data source as well as db corrections for npm and golang modules. Would you be able to provide a source we can scan that reproduces these FP if they're still valid?

Thanks again!

[thediveo]

@spiffcs https://github.com/thediveo/lxkns should suffice as a test, as it is the guinea pig repo where I tripped over the messed-up CVEs when letting syft+grype on the loose.

[OfriOuzan]

We encountered the same issue on the following environment What happened: In a Vulnerability Scanner Benchmark Research we are conducting, we executed Grype on 20 different containers and found out that Grype has multiple False Positives. What you expected to happen: We expected Grype not to report on these CVEs. How to reproduce it (as minimally and precisely as possible): Install the Docker Images (from the links below) and execute Grype using the following command: grype <container_name> —-output json > <output_file_path>

• Output of grype version: Application: grype Version: 0.41.0 Syft Version: v0.50.0 BuildDate: 2022-07-06T15:20:18Z GitCommit: 0e0a9d9e7a28592db489499db0294608e5fe69b8 GitDescription: v0.41.0 Platform: linux/amd64 GoVersion: go1.18.3 Compiler: gc Supported DB Schema: 4 Ghost

• Container Details: https://hub.docker.com/layers/library/ghost/5.2.4/images/sha256-42137b9bd1faf4cdea5933279c48a912d010ef614551aeb0e44308600aa3e69f?context=explore

• OS (e.g: cat /etc/os-release): PRETTY_NAME="Debian GNU/Linux 11 (bullseye)" NAME="Debian GNU/Linux" VERSION_ID="11" VERSION="11 (bullseye)" VERSION_CODENAME=bullseye ID=debian HOME_URL="https://www.debian.org/" SUPPORT_URL="https://www.debian.org/support" BUG_REPORT_URL="https://bugs.debian.org/"

• CVEs CVE-2009-4590, CVE-2009-4591, CVE-2009-4592 Grype wrongly identified CVE-2009-4590, CVE-2009-4591, CVE-2009-4592 as vulnerable. The path it identified is: /var/lib/ghost/versions/5.2.4/node_modules/base/package.json The base package version is 0.11.2 However, according to the debian website, the vulnerability is related to acidbase package which is not exists on the container. CVE-2013-1779 Grype wrongly identified CVE-2013-1779 as vulnerable. The path it identified is: /var/lib/ghost/versions/5.2.4/node_modules/fresh/package.json The fresh package version is 0.5.2. However, according to the debian website, the vulnerability is a drupal addon. CVE-2014-2980 Grype wrongly identified CVE-2014-2980 as vulnerable. The path it identified is: /var/lib/ghost/versions/5.2.4/node_modules/base/package.json The base package version is 0.11.2 However, according to the debian website, the vulnerability is related to the gnustep-base package which I did not find installed.

Kibana

• Container Details: https://hub.docker.com/layers/kibana/library/kibana/8.3.2/images/sha256-51635619b14a0f3a764f39c4c51d527304d8c33fbda05d72652b18255639122b?context=explore

• OS (e.g: cat /etc/os-release): NAME="Ubuntu" VERSION="20.04.4 LTS (Focal Fossa)" ID=ubuntu ID_LIKE=debian PRETTY_NAME="Ubuntu 20.04.4 LTS" VERSION_ID="20.04" HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" VERSION_CODENAME=focal UBUNTU_CODENAME=focal

• CVEs CVE-2020-7753 Grype wrongly identified CVE-2020-7753 as vulnerable. The path it identified is: /usr/share/kibana/node_modules/trim/package.json" The trim npm package version is 1.0.1 However, according to the snyk website, the affected versions range: Up to (Including) 0.0.3. The trott/trim has the 1.0.1 version and the component/trim only has the 0.0.1 version. The last time the component package was updated was in 2012 and the last time trott was updated was in 2021. The vulnerability is in the trott/trim. The following versions have the fixed commit: 0.0.2, 0.0.3, 1.0.0 and 1.0.1.

[willmurphyscode]

Thanks @thediveo! I think this has been fixed by intervening development:

cd /tmp
git clone [email protected]:thediveo/lxkns.git
grype dir:lxkns

prints only:

NAME                            INSTALLED            FIXED-IN      TYPE       VULNERABILITY        SEVERITY
github.com/docker/distribution  v2.8.1+incompatible  2.8.2-beta.1  go-module  GHSA-hqxw-f8mx-cpmw  High
github.com/sigstore/rekor       v1.1.1               1.2.0         go-module  GHSA-frqx-jfcm-6jjr  Medium

Thanks @OfriOuzan for adding additional sources that produce these false positives.

I'm no longer able to reproduce the issue with ghost:5.2.4:

grype --platform linux/amd64 \
ghost:5.2.4@sha256:42137b9bd1faf4cdea5933279c48a912d010ef614551aeb0e44308600aa3e69f | \
grep -e CVE-2009-4590 -e CVE-2009-4591 -e CVE-2009-4592

prints no vulnerabilities.

I'm also no longer able to produce the issue with kibana:8.3.2:

grype --platform linux/amd64 \
docker:kibana:8.3.2@sha256:51635619b14a0f3a764f39c4c51d527304d8c33fbda05d72652b18255639122b | \
grep CVE-2020-7753

prints no vulnerabilities.

I believe this was fixed in https://github.com/anchore/grype/releases/tag/v0.60.0, which stopped matching CPEs for npm packages by default.

[thediveo]

many thanks!

[willmurphyscode]

Added changelog-ignore because this was fixed in 0.60.0 and so shouldn't be included in the current release's release notes.