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

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

Closed
mssfang opened this issue Nov 21, 2022 · 4 comments
Closed
Labels
changelog-ignore Don't include this issue in the release changelog false-positive

Comments

@mssfang
Copy link

mssfang commented Nov 21, 2022

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.

@spiffcs spiffcs added this to OSS Nov 21, 2022
@spiffcs spiffcs moved this to False Positives in OSS Nov 21, 2022
@cezapata
Copy link

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 cezapata/appconfiguration-sample#1 but unsure if this is the proper way forward.

Thanks!

Dependency tree
Vulnerability output JSON

@kzantow
Copy link
Contributor

kzantow commented Nov 22, 2022

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

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:

#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:

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

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

@github-project-automation github-project-automation bot moved this to Done in OSS Jul 29, 2024
@wagoodman wagoodman added the changelog-ignore Don't include this issue in the release changelog label Jul 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
changelog-ignore Don't include this issue in the release changelog false-positive
Projects
Archived in project
Development

No branches or pull requests

5 participants