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.

Sign up for GitHub

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

Jump to bottom

Multiple False Positive and False Negative CVEs #3010

Closed
2 tasks done
OfriOuzan opened this issue Oct 12, 2022 · 8 comments
Closed
2 tasks done

Multiple False Positive and False Negative CVEs #3010

OfriOuzan opened this issue Oct 12, 2022 · 8 comments
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.

Comments

@OfriOuzan
Copy link

OfriOuzan commented Oct 12, 2022 •
edited

Checklist

  • I've read the documentation regarding wrong detection.
  • I've confirmed that a security advisory in data sources was correct.
    • Run Trivy with -f json that shows data sources and make sure that the security advisory is correct.

Description

What happened:
As part of a vulnerability scanner benchmark research we are conducting, we executed Trivy on 20 different containers and identified multiple misidentifications.

What you expected to happen:
We expected Trivy not to have these misidentifications.

How to reproduce it (as minimally and precisely as possible):
Install the Docker Images (from the links below) and execute Trivy using the following command:
trivy i -f json <container_name> > <output_file>

Output of trivy -v:

Version: 0.29.2
Vulnerability DB:
  Version: 2
  UpdatedAt: 2022-07-11 12:06:43.535213 +0000 UTC
  NextUpdate: 2022-07-11 18:06:43.5352126 +0000 UTC
  DownloadedAt: 2022-07-11 16:33:57.554982191 +0000 UTC

Additional Information

Examples include:

  • 93 cves
    In the following container images:
    Drupal
    NextCloud
    Wordpress
    Trivy wrongly associated linux-libc-dev with CVEs affecting the linux kernel. Some of the vulnerabilities identified are associated with a much older kernel version the the linc-dev version (for example CVE-2005-3660 in the drupal container), but we think the problem is more fundamental in nature from two main reasons:
  1. linux-libc-dev does not contain the relevant cide for most of the identified vulnerabilities.
  2. Even if it did, flagging kernel vulnerabilities from within containers doesn’t really serve a purpose for the user since the kernel version relevant for kernel vulnerabilities should be the external kernel version (the one running on the host). Even in the rare case in which the linux-libc-dev or linux-libc version on the container matches the kernel version on the host, upgrading linc on the container will not solve the problem as the libc code that will be used as part of the normal container operation will be the libc version of the host.

  • CVE-2022-21698
    Trivy did not identify CVE-2022-21698 as vulnerable.
    According to https://pkg.go.dev/vuln/GO-2022-0322 the affected package is github.com/prometheus/client_golang/prometheus/promhttp and the affected versions are v1.11.1 and earlier.
    The found dependency is: github.com/prometheus/client_golang in the consul file with the v1.4.0 version.
    dep github.com/prometheus/client_golang v1.4.0

  • CVE-2022-27191
    Trivy did not identify CVE-2022-27191 as vulnerable.
    According to https://pkg.go.dev/vuln/GO-2021-0356, affected package is golang.org/x/crypto/ssh affected versions are Up to (excluding) 0.0.0-20220314234659-1baeb1ce4c0b.
    The found dependency is: golang.org/x/crypto dependency version v0.0.0-20210513164829-c07d793c2f9a in the consul elf file.
    dep golang.org/x/crypto v0.0.0-20210513164829-c07d793c2f9a
    crypto uses an ssh version from May 2021 which is before March 2022.

  • CVE-2022-28948
    Trivy did not identify CVE-2022-28948 as vulnerable.
    According to nvd, affected versions are all Go-Yaml v3.
    According to https://pkg.go.dev/vuln/ the affected package is gopkg.in/yaml.v3, affected versions range is: from v3.0.0 before v3.0.1.
    The found dependency is: gopkg.in/yaml.v3 dependency version v3.0.0-20200313102051-9f266ea9e77c in the consul elf file.
    dep gopkg.in/yaml.v3 v3.0.0-20200313102051-9f266ea9e77c.
    The fix commit in the go-yaml repository, is associated with the 3.0.0 version, meaning that every other version other than 3.0.0 (for example v3.0.0-20200313102051-9f266ea9e77c) is affected by the vulnerability.

  • CVE-2017-16137
    Trivy did not identify CVE-2017-16137 as vulnerable.
    The identified path is:
    /var/lib/ghost/versions/5.2.4/node_modules/brute-knex/node_modules/debug/package.json
    The debug package version is 4.1.1
    According to the NVD website, the vulnerability affected versions are From (including) 2.0.0 Up to (excluding) 2.6.9 and From (including) 3.0.0 Up to (excluding) 3.1.0
    The debug versions I found on the container are: 0.1.17, 2.6.9, 3.1.0, 3.2.7, 4.1.1, 4.3.4
    However, according to this link, the vulnerability that was fixed in the f53962e was accidentally introduced in 7116906.
    So, the updated affected versions range is: From (including) 2.0.0 Up to (excluding) 2.6.9 and From (including) 3.0.0 Up to (excluding) 3.1.0 and From (including) 4.0.0 Up to (excluding) 4.3.1.

  • CVE-2022-2191
    Trivy wrongly identified jetty CVE-2022-2191 as vulnerable.
    The actual version they both found is 9.4.46.v20220331, the affected versions are From (including) 10.0.0 Up to (including) 10.0.9 and From (including) 11.0.0 Up to (including) 11.0.9. The version is not within the affected range.
    Also, according to this link, a contributor of jetty project mentioned that jetty versions 9.x are not affected by this vulnerability.

  • CVE-2022-32212, CVE-2022-32213, CVE-2022-32214, CVE-2022-32223
    Trivy did not identify the following cves as vulnerable:
    CVE-2022-32212, CVE-2022-32213, CVE-2022-32214, CVE-2022-32223.
    I found this file /usr/share/kibana/node/bin/node and when executing the path with -v it prints the 16.14.2 version.
    Then we found on the docker file the following command: COPY /usr/share/kibana /usr/share/kibana.

  • CVE-2020-3810
    Trivy did not identify CVE-2020-3810 as vulnerable.
    According to nvd, the affected apt versions are: Up to (excluding) 2.1.2.
    According to Ubuntu, the fixed version for focal distribution is: 2.0.2ubuntu0.1.
    The actual version is 2.0.9.
    The fixed commit in apt lists the fixed versions and 2.0.9 is not one of them.

  • CVE-2020-13955
    Trivy did not identify calcite CVE-2020-13955 as vulnerable.
    Affected versions are: Up to (excluding) 1.26.
    The found avatica-core path is: /opt/solr-9.0.0/modules/sql/lib/avatica-core-1.18.0.jar
    Actual version is: 1.18.0
    Avatica-core is a subproject of calcite.

  • CVE-2021-43045
    Trivy did not identify avro CVE-2021-43045 as vulnerable.
    Affected versions are: Up to (including) 1.10.2.
    Actual version: 1.7.7.
    According to ubuntu: Jammy - Needs triage.
    The avro package is in this path: /opt/solr-9.0.0/modules/hdfs/lib/hadoop-client-runtime-3.3.2.jar
    After extracting the jar file, the META-INF/maven/org.apache.avro/avro/pom.xml file contains the following:
    org.apache.avro
    1.7.7
    Also the pom.xml file has a reference to the apache avro.
    According to nvd the affected package is an apache avro nuget package.

  • CVE-2022-25169
    Trivy did not identify tika CVE-2022-25169 as vulnerable. According to nvd, affected tika versions are Up to (excluding) 1.28.2, From (including) 2.0.0 Up to (excluding) 2.4.0.
    The founded path is: /opt/solr-9.0.0/modules/langid/lib/tika-core-1.28.1.jar

  • CVE-2022-30126
    Trivy did not identify tika CVE-2022-30126 as vulnerable. According to nvd, affected tika versions are Up to (excluding) 1.28.2, From (including) 2.0.0 Up to (excluding) 2.4.0.
    Actual version: 1.28.1 (found in jar file only)

  • CVE-2022-30973
    Trivy did not identify tika CVE-2022-30973 as vulnerable. According to nvd, affected tika versions are Up to (excluding) 1.28.3.
    Actual version: 1.28.1 (found in jar file only)

  • CVE-2022-33879
    Trivy did not identify tika CVE-2022-33879 as vulnerable. According to nvd, affected tika versions are Up to (excluding) 1.28.4, From (including) 2.0.0 Up to (excluding) 2.4.1.
    Actual version: 1.28.1 (found in jar file only)

  • CVE-2021-31684
    Trivy did not identify json-smart CVE-2021-31684 as vulnerable.
    Actual version: 1.3.2
    Affected versions are: From (including) 1.3 Up to (excluding) 1.3.3, From (including) 2.4 Up to (excluding) 2.4.4
    The json-smart that found was in /opt/solr-9.0.0/modules/hdfs/lib/hadoop-client-runtime-3.3.2.jar
    After extracting this file, the META-INF/maven/net.minidev/json-smart/pom.properties file contains the following:
    artifactId=json-smart
    version=1.3.2

  • CVE-2016-2402
    Trivy wrongly identified okHttp CVE-2016-2402 as vulnerable.
    According to nvd, affected okHttp versions are before 2.7.4 and 3.x before 3.1.2
    Actual version: 4.9.3.
    Trivy identified the okHttp package in this path: opt/solr-9.0.0/modules/hadoop-auth/lib/commons-configuration2-2.7.jar
    I can not find any connection between the okHttp and the commons-configuration.

  • CVE-2022-24823
    Trivy did not identify netty CVE-2022-24823 as vulnerable. According to nvd, affected netty versions areUp to (excluding) 4.1.77.
    Actual version: 4.1.68.Final
    According to ubuntu:Jammy - Needs triage.

  • CVE-2021-42377
    Trivy did not identify CVE-2021-42377 as vulnerable.
    The affected busybox versions range is: 1.33.0 and 1.33.1.
    According to nvd, the affected cpe is: cpe:2.3:a:busybox:busybox:1.33.1:::::::*
    The actual version is: 1.33.1-r7.

  • CVE-2022-21476
    Trivy did not identify CVE-2022-21476 as vulnerable.
    The ncurses-libs affected versions range for Alpine 3.14 is: Up to (excluding) 6.2_p20210612-r1.
    The actual version is: 6.2_p20210612-r0.

  • CVE-2022-28506
    Trivy did not identify CVE-2022-28506 as vulnerable.
    The giflib affected version is: 5.2.1 vulnerable.
    The actual version is: 5.2.1-r0.

  • CVE-2022-29458
    Trivy did not identify CVE-2022-29458 as vulnerable.
    The ncurses-libs affected version is: 6.3 before patch 20220416.
    The actual version is: 6.2_p20210612-r0.

  • CVE-2020-28491
    Trivy did not identify CVE-2020-28491 as vulnerable.
    The jackson-dataformats-binary affected version is: Up to (excluding) 2.11.4.
    The actual version is: 2.10.4.

  • CVE-2022-2068
    Trivy did not identify CVE-2022-2068 as vulnerable.
    The openssl affected versions range is: From (including) 1.1.1 Up to (excluding) 1.1.1p.
    The actual version is: 1.1-1.1.1n-r0.
    According to security alpine and the alpine secdb, we assume that all openssl versions of Alpine 3.14 are affected by the vulnerability.

  • CVE-2022-21476, CVE-2022-21496, CVE-2022-21426, CVE-2022-21434, CVE-2022-21443
    Trivy did not identify CVE-2022-21476, CVE-2022-21496, CVE-2022-21426, CVE-2022-21434, CVE-2022-21443 as vulnerable.
    The actual version is: 11.0.14_p9-r0.
    According to Alpine security, the cpe for 11.0.14 is: cpe:2.3:a:oracle:jre:11.0.14:::::::*
    Means that all versions of 11.0.14 are affected by these vulnerabilities.

  • CVE-2021-42376, CVE-2021-42379, CVE-2021-42373, CVE-2021-42381, CVE-2021-42382, CVE-2021-42374, CVE-2021-42386, CVE-2021-42384, CVE-2021-42383, CVE-2021-42385, CVE-2021-42380, CVE-2021-42378, CVE-2022-28391, CVE-2021-42375.
    Trivy did not identify cves as vulnerable:
    CVE-2021-42376, CVE-2021-42379, CVE-2021-42373, CVE-2021-42381, CVE-2021-42382, CVE-2021-42374, CVE-2021-42386, CVE-2021-42384, CVE-2021-42383, CVE-2021-42385, CVE-2021-42380, CVE-2021-42378, CVE-2022-28391, CVE-2021-42375.
    According to NVD affected busybox versions range is: From (including) 1.16.0.Up to (excluding) 1.34.0.
    According to this website: https://security.alpinelinux.org/srcpkg/busybox
    One of the resolved cves for the Alpine 1.14 busybox 1.33.1-r8 version is CVE-2021-42376.
    The actual version is: 1.33.1-r7

  • CVE-2022-34305
    Trivy did not identify tomcat CVE-2022-34305 as vulnerable.
    According to nvd, affected tomcat versions are From (including) 8.5.50 Up to (including) 8.5.81, From (including) 9.0.30 Up to (including) 9.0.64, From (including) 10.0.0 Up to (including) 10.0.22.
    Actual version: 10.0.22
    Did not find information on the Ubuntu website for Jammy.

  • CVE-2020-0478
    Trivy did not identify CVE-2020-0478 as vulnerable.
    The affected package is: aom.
    The affected version range: bullseye - 1.0.0.errata1-3 vulnerable
    The actual version is: 1.0.0.errata1-3.

The containers used for the research were:

Container Version Link
Jenkins 2.358 https://hub.docker.com/layers/jenkins/jenkins/2.358/images/sha256-01600c1acde3391286945f775f2e5b2366f9b96fbe012a3ffa5159073c0c6392?context=explore
Drupal 9.4.2 https://hub.docker.com/layers/library/drupal/9.4.2/images/sha256-b370968f989cddff5c0581d8093d65be8e0733176fe987d946114a11ada047d8?context=explore
MariaDB 1:10.8.3+maria~jammy https://hub.docker.com/layers/library/mariadb/10.8.3/images/sha256-0a6ed934c1518abff64ed856b06f44006b4498b115941e19bbd910bd62a12232?context=explore
NextCloud 24.0.2 https://hub.docker.com/layers/library/nextcloud/24.0.2/images/sha256-f414023e31cfe6b157e76648c8ad021aab5491cbbb28f96939ae6dd874729ace?context=explore
Redis 7.0.2 https://hub.docker.com/layers/library/redis/7.0.2/images/sha256-31120dcdd310e9a65cbcadd504f4fe60a185bd634ab7c6a35e3e44a941904d97?context=explore
Tomcat 10.0.22 https://hub.docker.com/layers/library/tomcat/10.0.22/images/sha256-71444268934d60df07205e89f1f7a66df2852c7712063b8fa921828c94f169f6?context=explore
Wordpress 6.0 https://hub.docker.com/layers/library/wordpress/6.0.0-php7.4-fpm/images/sha256-ab9da08aca4576011afaa990295581b9f34ece4b1a0ce827a734264547064498?context=explore
Rabbitmq 3.10.5 https://hub.docker.com/layers/rabbitmq/library/rabbitmq/latest/images/sha256-45b2855afa95e7d483b4850bec8a5484031b94f9c72d5476a3900b7788a8fc74?context=explore
Ghost 5.2.4 https://hub.docker.com/layers/library/ghost/5.2.4/images/sha256-42137b9bd1faf4cdea5933279c48a912d010ef614551aeb0e44308600aa3e69f?context=explore
Memcached 1.6.15 https://hub.docker.com/layers/library/memcached/1.6.15/images/sha256-1fb5662239cfb3d632efd4df609caff38f0bac3e78bd0cf6db038d5a6a818147?context=explore
Postgres 14.4-1.pgdg110+1 https://hub.docker.com/layers/library/postgres/14.4/images/sha256-cf3b0cf1dde2a82542e4b9de7f3ad058fdc819dea6499007035b838542b0bd5e?context=explore
Httpd 2.4.54 https://hub.docker.com/layers/library/httpd/2.4.54/images/sha256-facd7a9ef4225c56d531cc2d1c26a0576edf417fb6d49f2f1b279994a8387666?context=explore
Consul 1.12.2 https://hub.docker.com/layers/library/consul/1.12.2/images/sha256-a1a933572cb6f6388501c535af455f77e687c62ff97ed72cd16301b8b535eae0?context=explore
Nginx 1.23.0 https://hub.docker.com/layers/library/nginx/1.23.0/images/sha256-33cef86aae4e8487ff23a6ca16012fac28ff9e7a5e9759d291a7da06e36ac958?context=explore
MySQL 8.0.29-1debian11 https://hub.docker.com/layers/library/mysql/8.0.29-debian/images/sha256-3a7e864bc88458911fa598065fe027736fa63495f5780ee0618caeb4a52bbc4c?context=explore
Mongo 5.0.9 https://hub.docker.com/layers/library/mongo/5.0.9/images/sha256-4b58442ec48034662c5581405a24755bdd80730535ccb98e262b6f5ed76c7017?context=explore
Sonarqube 9.5.0.56709 https://hub.docker.com/layers/library/sonarqube/9.5.0-community/images/sha256-2f102e5b91abb39db22da3d2efca1eaccdd919923355b6e42edc3c522e3aa235?context=explore
Kibana 8.3.2 https://hub.docker.com/layers/kibana/library/kibana/8.3.2/images/sha256-51635619b14a0f3a764f39c4c51d527304d8c33fbda05d72652b18255639122b?context=explore
Neo4j 4.4.8 https://hub.docker.com/layers/library/neo4j/4.4.8/images/sha256-d7cb5bde33a15197f45ca2f8a701de059c9e33cc6b59a7d7a02c180462ea98c0?context=explore
Solr 9.0.0 https://hub.docker.com/layers/library/solr/9.0.0/images/sha256-a75d693dcc9b978f8f35cdad3f775ad09dd3020e1920871a1fb167655a19e888?context=explore

@OfriOuzan OfriOuzan added the kind/bug Categorizes issue or PR as related to a bug. label Oct 12, 2022
@knqyf263
Copy link
Collaborator

Did you refer to security advisories from each vendor rather than NVD?

@OfriOuzan
Copy link
Author

Yes, of course.
I referred to the os distribution security advisory and in some cases to the snyk vulnerability db.
In the golang dependencies I added links to the website in which I referred to.

@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Dec 12, 2022
@ArielPrevu3D
Copy link

Is there a reason why headers from linux-libc-dev are considered to be a kernel vulnerability with the image?

@github-actions github-actions bot removed the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Dec 13, 2022
@Cpt-Falcon
Copy link

All of these fall positives and fake warnings are deceptive. It's confusing to new users of the tool to see a bunch of fake red herrings. So many base images supposedly have all these vulnerabilities even though Microsoft, the node js group, and many other groups reject these supposed vulnerabilities as real issues.

Does the node js slim image version 14.15.5-slim debian really have:
Total: 237 (UNKNOWN: 4, LOW: 120, MEDIUM: 30, HIGH: 52, CRITICAL: 31)
vulnerabilities? Of course not, this is a laughable estimation. It makes it so the tool is unusable. How can I sift through all of the false positives in a reasonable amount of time? There is simply no way these base images have so many vulnerabilities.

@Cpt-Falcon
Copy link

Source graph does a good job of exposing the problems here:

“Accepted vulnerabilities and false positives
Trivy finds many vulnerabilities that are either false positives (where we are not actually vulnerable) or that we decide to accept because it presents low risk to us. It’s not expected for all images to be cleared of all High/Critical CVEs due to these issues with the tool. This is according to our Vulnerability Management Policy. Current CVEs that are accepted or false positives are documented here.”

https://handbook.sourcegraph.com/departments/security/tooling/trivy/

@tspearconquest
Copy link
Contributor

@OfriOuzan I believe that your false positives are now fixed. Trivy leverages the GHSA database and I see that the false positive entries you highlighted (Jetty and OkHttp) were updated last week. Comparing the current version data against what I can see for these 2 in the Google cached results, it appears that if you scan those again, you should no longer see them being reported as vulnerable.

Regarding the false negatives, I will leave this to Trivy team to assess further.

@Cpt-Falcon Hello! Based on your comments, (and I am a user here, not part of Aqua/Trivy team) I think this is not a Trivy issue but rather it is a lack of understanding of the scope of what Trivy can support.

So many base images supposedly have all these vulnerabilities even though Microsoft, the node js group, and many other groups reject these supposed vulnerabilities as real issues.

These rejections by open source teams are not rejections of the vulnerability itself. They are rejections of whether the vulnerability is exploitable through those teams' code. I'll use node js as an example. What this means is, let's say someone reports to the node js group that a CVE is found in a library that the node.js container uses. node.js may not call the function from that library which is exploitable. So node js group rejects the vulnerability based on the fact that you cannot exploit the vulnerability through node.js itself.

This means that while node.js uses the library, the node js group has determined that there is no risk that applications built using the node js container can be leveraged to exploit the vulnerability, because node.js never uses the vulnerable code from that library. The library itself is vulnerable and someone would have to write some code into node.js which exploits the vulnerability in that library, then get that code accepted into the upstream project before the node js container would become vulnerable. While supply chain attacks do happen, this is typically difficult to pull off.

This does mean that you end up seeing a lot of what you call red herring issues. Unfortunately, as I mentioned above, it is simply beyond the scope of what Trivy can support, because in essence, what you're asking for is to make Trivy become a dynamic vulnerability scanner where someone from the Aqua/Trivy team would need to write actual exploit code to test for these vulnerabilties, and that would require writing code against every container that uses a given library, in order to test that the container leverages the vulnerability within its dependencies.

This is impractical because there are hundreds of containers that may use a library, and each container would require a custom-written test. The purpose of Trivy scanning for dependencies in the first place is to allow you to protect your own code by not calling functions in your dependencies that have been found to have a vulnerability. When you scan third party containers, often times it's best to simply refer to the upstream team who created that container to determine if they are vulnerable. If they reject the CVE (as you mentioned) then you can simply ignore it, or feel free to fork the project to your internal repo and patch the affected library yourself.

I present the following excerpt from your link as evidence of what I've said above:

If a component or base image has a CVE we decide whether to patch it based on the risk of the vulnerability and of the patch. For example, if we have a High severity CVE but that actually does not present risk to our application and the upgrade is of several major versions we may choose to not upgrade. On the other hand, if the patches are available for minor versions we should always patch regardless of the vulnerability risk.

This is the approach we take in my org as well. For example, for container images which run our in-house applications, if we are using a library which was flagged by Trivy as having a CVE, we will investigate the CVE to determine if our code calls the vulnerable function. If we don't call the vulnerable function, then there is no risk our application can be leveraged in an attack. If we find that the vulnerability may be exploitable in our in-house application, then we will patch it if a patch is available upstream. If a patch is not available from the upstream team, then we may decide to fork the upstream repo to our own repo and make the patch available internally ourselves, depending on certain criteria related to risk.

Hope this helps!

@github-actions
Copy link

This issue is stale because it has been labeled with inactivity.

@github-actions github-actions bot added the lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed. label Mar 23, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 14, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
kind/bug Categorizes issue or PR as related to a bug. lifecycle/stale Denotes an issue or PR has remained open with no activity and will be auto-closed.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
5 participants
@knqyf263 @Cpt-Falcon @ArielPrevu3D @tspearconquest @OfriOuzan