search

anchore / grype

A vulnerability scanner for container images and filesystems
Apache License 2.0
8.87k stars 574 forks source link

False positive vulnerabilities on `reactor-netty-core` and `reator-netty-http` #1009

Closed mssfang closed 3 months ago

mssfang commented 2 years ago

Running the latest grype tool on an application takes a dependency on io.projectreactor.netty:reactor-netty-http:jar:1.0.24:compile which along with io.projectreactor.netty:reactor-netty-core:jar:1.0.24:compile and complaints on those vulnerabilities.

NAME                     INSTALLED  FIXED-IN  TYPE          VULNERABILITY        SEVERITY
reactor-netty-core       1.0.24               java-archive  CVE-2014-3488        Medium
reactor-netty-core       1.0.24               java-archive  CVE-2019-16869       High
reactor-netty-core       1.0.24               java-archive  CVE-2021-21290       Medium
reactor-netty-core       1.0.24               java-archive  CVE-2021-21295       Medium
reactor-netty-core       1.0.24               java-archive  CVE-2019-20445       Critical
reactor-netty-core       1.0.24               java-archive  CVE-2021-37137       High
reactor-netty-core       1.0.24               java-archive  CVE-2022-24823       Medium
reactor-netty-core       1.0.24               java-archive  CVE-2019-20444       Critical
reactor-netty-core       1.0.24               java-archive  CVE-2021-43797       Medium
reactor-netty-core       1.0.24               java-archive  CVE-2015-2156        High
reactor-netty-core       1.0.24               java-archive  CVE-2021-21409       Medium
reactor-netty-core       1.0.24               java-archive  CVE-2021-37136       High
reactor-netty-http       1.0.24               java-archive  CVE-2019-20444       Critical
reactor-netty-http       1.0.24               java-archive  CVE-2021-21290       Medium
reactor-netty-http       1.0.24               java-archive  CVE-2021-37136       High
reactor-netty-http       1.0.24               java-archive  CVE-2015-2156        High
reactor-netty-http       1.0.24               java-archive  CVE-2019-20445       Critical
reactor-netty-http       1.0.24               java-archive  CVE-2021-21295       Medium
reactor-netty-http       1.0.24               java-archive  CVE-2021-21409       Medium
reactor-netty-http       1.0.24               java-archive  CVE-2021-37137       High
reactor-netty-http       1.0.24               java-archive  CVE-2014-3488        Medium
reactor-netty-http       1.0.24               java-archive  CVE-2019-16869       High
reactor-netty-http       1.0.24               java-archive  CVE-2021-43797       Medium
reactor-netty-http       1.0.24               java-archive  CVE-2022-24823       Medium

Found those vulnerabilities should have already been fixed in the earlier version of reactor netty . such as CVE-2019-20445 which fixed on 4.1.44 but reactor-netty-core:jar:1.0.24 already use 4.1.84 which is a newer version than 4.1.44.

Those vulnerabilities error should be false positives.

Can someone have a look and help? Thank you.

cezapata commented 2 years ago

I have created a sample to test this. You can take a look and play with it here:

https://github.com/cezapata/appconfiguration-sample

I have noticed two things that seem strange to me:

  1. The first one is that the reactor-netty packages (reactor-netty-http and reactor-netty-core) are matching the CPE of the vulnerability for netty (see on the output JSON). I am curious as to how CPEs are created, because even though they have netty within the name, each package is independent and handles its versioning differently. As @mssfang mentions, the reactor-netty packages that were published with version 1.0.24 are consuming netty version 4.1.82.Final for which all the vulnerabilities listed above are fixed. The same happens with the maven / maven-wrapper vulnerability in my repo above. Somehow, maven-wrapper is getting resolved to the maven CPE, which causes it to be flagged. I would like to understand how CPEs are calculated and if it is a misunderstanding on my side.

  2. I noticed another issue, where if you have declared a dependency on the parent, it seems like you need to hardcode the version on the child for grype to pick it up properly (if you look at the dependency tree, it is able to calculate the dependency properly from the parent but grype complains):

image

Any clarification or guidance on these issues would be greatly appreciated. On the meantime, I am peppering exclusions to grype as per https://github.com/cezapata/appconfiguration-sample/pull/1 but unsure if this is the proper way forward.

Thanks!

Dependency tree Vulnerability output JSON

kzantow commented 2 years ago

Regarding the false positives: @cezapata is right that this is due to CPE generation. CPE is definitely the largest source of false positives, but these are very challenging because the CPEs chosen for NVD mean it is difficult to map any arbitrary software to an accurate CPE, which is why a lot of derivations are generated -- which leads to fewer missed vulnerabilities but increases the false positives. We are actively investigating ways to improve this.

Regarding the version issue -- remind me: where does the child version come from? Is it always the same as the parent version or is it read from some field in the parent pom? (We should split this into a separate issue)

cezapata commented 2 years ago

Thank you so much for looking into this @kzantow! I see now there was already an ongoing thread about handling CPEs and similar problems here:

https://github.com/anchore/grype/issues/431

As a mitigation, I will just use the ignore field and a combination of package names and vulnerabilities to handle these.

Two suggestions that would improve the developer experience when working with the ignore setting on the yaml configuration would be:

  1. Allowing 1 vulnerability to map to multiple conditions, for instance, allowing us to map to multiple package names, as opposed to just one, and having to add a separate entry.
  2. Allowing us to add comparison strings on the version (for instance, "version": ">=1.0.24" meaning that any version over 1.0.23 would be excluded.

I can imagine the complexity of adding those conditions (basically having to have nested conditions with and ors, and also some grammar to implement the comparison among versions, I can see how those are not easy fixes to implement, but just suggestions :)

Finally, I have created an independent issue for the parent version:

https://github.com/anchore/grype/issues/1012

I do believe it will map to the parent's version field, unless overridden at the child itself.

Thanks again for your quick reply and your help!

wagoodman commented 3 months ago

We've confirmed that this has been fixed in the latest version of grype

❯ curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- v0.52.0

❯ ./bin/grype ./reactor-netty-core-1.0.24.jar
 ✔ Vulnerability DB        [no update available]
New version of grype is available: 0.79.3 (currently running: 0.52.0)
 ✔ Indexed reactor-netty-core-1.0.24.jar
 ✔ Cataloged packages      [1 packages]
 ✔ Scanned image           [14 vulnerabilities]

NAME                INSTALLED  FIXED-IN  TYPE          VULNERABILITY   SEVERITY
reactor-netty-core  1.0.24               java-archive  CVE-2021-43797  Medium
reactor-netty-core  1.0.24               java-archive  CVE-2015-2156   High
reactor-netty-core  1.0.24               java-archive  CVE-2019-16869  High
reactor-netty-core  1.0.24               java-archive  CVE-2021-21409  Medium
reactor-netty-core  1.0.24               java-archive  CVE-2021-37136  High
reactor-netty-core  1.0.24               java-archive  CVE-2022-41881  High
reactor-netty-core  1.0.24               java-archive  CVE-2021-21295  Medium
reactor-netty-core  1.0.24               java-archive  CVE-2023-34462  Medium
reactor-netty-core  1.0.24               java-archive  CVE-2014-3488   Medium
reactor-netty-core  1.0.24               java-archive  CVE-2019-20444  Critical
reactor-netty-core  1.0.24               java-archive  CVE-2019-20445  Critical
reactor-netty-core  1.0.24               java-archive  CVE-2021-21290  Medium
reactor-netty-core  1.0.24               java-archive  CVE-2021-37137  High
reactor-netty-core  1.0.24               java-archive  CVE-2022-24823  Medium

grype ./reactor-netty-core-1.0.24.jar
 ✔ Vulnerability DB                [no update available]
 ✔ Indexed file system                                                                                                                                                   /Users/wagoodman/scratch/grype-1009
 ✔ Cataloged contents                                                                                                                       27d703e707e55d43ca1475c9bb122ce3334fc055c08320631c71c3f06728f1d1
   ├── ✔ Packages                        [1 packages]
   └── ✔ Executables                     [0 executables]
 ✔ Scanned for vulnerabilities     [0 vulnerability matches]
   ├── by severity: 0 critical, 1 high, 0 medium, 0 low, 0 negligible
   └── by status:   1 fixed, 0 not-fixed, 0 ignored
NAME                INSTALLED  FIXED-IN  TYPE          VULNERABILITY        SEVERITY
reactor-netty-core  1.0.24     1.0.39    java-archive  GHSA-q24v-hpg3-v3jp  High