Inconsistencies between standard and light database (re: CVE-2021-44228) #1453
Comments
|
Happens for me as well. The interesting thing - both light and standard databases have CVE-2021-44228 inside, but for some reason with |
|
Another thing - according to https://nvd.nist.gov/vuln/detail/CVE-2021-44228 the I'm not sure where does the information about |
|
Now it's being reported separately, but
$ trivy image --ignore-unfixed --severity CRITICAL bitnami/elasticsearch
2021-12-11T19:51:11.390Z INFO Detected OS: debian
2021-12-11T19:51:11.390Z INFO Detecting Debian vulnerabilities...
2021-12-11T19:51:11.416Z INFO Number of language-specific files: 3
2021-12-11T19:51:11.416Z INFO Detecting gobinary vulnerabilities...
2021-12-11T19:51:11.416Z INFO Detecting jar vulnerabilities...
Java (jar)
==========
Total: 2 (CRITICAL: 2)
+-------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+-------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| org.apache.logging.log4j:log4j-api | CVE-2021-44228 | CRITICAL | 2.11.1 | 2.15.0 | log4j-core: Remote code execution |
| | | | | | in Log4j 2.x when logs contain |
| | | | | | an attacker-controlled... |
| | | | | | -->avd.aquasec.com/nvd/cve-2021-44228 |
+-------------------------------------+ + + + + +
| org.apache.logging.log4j:log4j-core | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
+-------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+
$ trivy image --ignore-unfixed --severity CRITICAL bitnami/keycloak
2021-12-11T19:52:43.479Z INFO Detected OS: debian
2021-12-11T19:52:43.479Z INFO Detecting Debian vulnerabilities...
2021-12-11T19:52:43.491Z INFO Number of language-specific files: 3
2021-12-11T19:52:43.491Z INFO Detecting gobinary vulnerabilities...
2021-12-11T19:52:43.491Z INFO Detecting jar vulnerabilities...
Java (jar)
==========
Total: 1 (CRITICAL: 1)
+------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| LIBRARY | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION | TITLE |
+------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+
| org.apache.logging.log4j:log4j-api | CVE-2021-44228 | CRITICAL | 2.14.0 | 2.15.0 | log4j-core: Remote code execution |
| | | | | | in Log4j 2.x when logs contain |
| | | | | | an attacker-controlled... |
| | | | | | -->avd.aquasec.com/nvd/cve-2021-44228 |
+------------------------------------+------------------+----------+-------------------+---------------+---------------------------------------+ |
|
@mih-kopylov @carrodher Thanks for reporting the issue! Trivy depends on GitHub Security Advisory (GHSA) and it includes log4j-api.
Could you report the issue to GHSA like this? |
|
@pablogalegoc Thank you for filing an issue. Please let me look into the issue. Meanwhile, use Trivy without |
|
@pablogalegoc thanks for your report! |
|
@knqyf263 If the light version of the DB is planned to be removed, my suggestion is to point it out in the documentation side. |
|
@recena Not ready yet. Once we finish preparation, We'll announce it. |
if the vulnerability doesn't contain a known vendor severity, `trivy` will set up a severity from the first vendor. fixes aquasecurity#1453
|
@knqyf263 But you plan to do it, the community should be aware of it. |
|
@recena No, I don't think so. We will announce enough period for the migration. It will confuse users to announce it before we are not ready. We have not yet decided when and how it will be deprecated at all. |
|
@knqyf263 does Trivy get it's data from any other sources? Can't find reference to this in docs. |
|
Are you talking about data sources? |
Description
When running a Trivy scan with a freshly downloaded standard database, the latest log4j CVE (
CVE-2021-44228) is reported, while running the same command with--light, again with a freshly downloaded database, fails to report it.What did you expect to happen?
Outputs from standard and light databases report the same vulnerabilities.
What happened instead?
Output from standard database is inconsistent with the report of the light database. Standard database seems more updated.
Output of run with
-debug:Output of
trivy -v:Additional details (base image name, container registry info...):
Base image:
bitnami/keycloak:15.0.2-debian-10-r106Container registry: Dockerhub
The text was updated successfully, but these errors were encountered: