Ignore Debian minor issues

[falcantaralinode]

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

Trivy considers this dependency db5.3 as a critical severity under the debian:11.6-slim image. The vulnerability is related to a heap out-of-bound read in the rtreenode() function when handling invalid rtree tables.

Debian considers this vulnerabilty to be a minor issue. Debian does have a security tracker. I saw that trivy uses this link for debian related os pkg vulnerabilities. It might be worth using this JSON file as another data source for reviewing Debian related vulnerabilities.

JSON Output of run with -debug:

{
          "VulnerabilityID": "CVE-2019-8457",
          "PkgID": "libdb5.3@5.3.28+dfsg1-0.8",
          "PkgName": "libdb5.3",
          "InstalledVersion": "5.3.28+dfsg1-0.8",
          "Layer": {
            "Digest": "sha256:26c5c85e47da3022f1bdb9a112103646c5c29517d757e95426f16e4bd9533405",
            "DiffID": "sha256:ed7b0ef3bf5bbec74379c3ae3d5339e666a314223e863c70644f7522a7527461"
          },
          "SeveritySource": "nvd",
          "PrimaryURL": "https://avd.aquasec.com/nvd/cve-2019-8457",
          "DataSource": {
            "ID": "debian",
            "Name": "Debian Security Tracker",
            "URL": "https://salsa.debian.org/security-tracker-team/security-tracker"
          },
          "Title": "sqlite: heap out-of-bound read in function rtreenode()",
          "Description": "SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-of-bound read in the rtreenode() function when handling invalid rtree tables.",
          "Severity": "CRITICAL",
          "CweIDs": [
            "CWE-125"
          ],
          "CVSS": {
            "nvd": {
              "V2Vector": "AV:N/AC:L/Au:N/C:P/I:P/A:P",
              "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
              "V2Score": 7.5,
              "V3Score": 9.8
            },
            "redhat": {
              "V3Vector": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
              "V3Score": 7.5
            }
          },
          "References": [
            "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00074.html",
            "https://access.redhat.com/security/cve/CVE-2019-8457",
            "https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-8457",
            "https://kc.mcafee.com/corporate/index?page=content\u0026id=SB10365",
            "https://linux.oracle.com/cve/CVE-2019-8457.html",
            "https://linux.oracle.com/errata/ELSA-2020-1810.html",
            "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/OPKYSWCOM3CL66RI76TYVIG6TJ263RXH/",
            "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/SJPFGA45DI4F5MCF2OAACGH3HQOF4G3M/",
            "https://nvd.nist.gov/vuln/detail/CVE-2019-8457",
            "https://security.netapp.com/advisory/ntap-20190606-0002/",
            "https://ubuntu.com/security/notices/USN-4004-1",
            "https://ubuntu.com/security/notices/USN-4004-2",
            "https://ubuntu.com/security/notices/USN-4019-1",
            "https://ubuntu.com/security/notices/USN-4019-2",
            "https://usn.ubuntu.com/4004-1/",
            "https://usn.ubuntu.com/4004-2/",
            "https://usn.ubuntu.com/4019-1/",
            "https://usn.ubuntu.com/4019-2/",
            "https://www.cve.org/CVERecord?id=CVE-2019-8457",
            "https://www.oracle.com/security-alerts/cpuapr2020.html",
            "https://www.oracle.com/security-alerts/cpujan2020.html",
            "https://www.oracle.com/security-alerts/cpujul2020.html",
            "https://www.oracle.com/technetwork/security-advisory/cpuoct2019-5072832.html",
            "https://www.sqlite.org/releaselog/3_28_0.html",
            "https://www.sqlite.org/src/info/90acdbfce9c08858"
          ],
          "PublishedDate": "2019-05-30T16:29:00Z",
          "LastModifiedDate": "2021-07-31T08:15:00Z"
},

Output of trivy -v:

Version: 0.40.0
Vulnerability DB:
  Version: 2
  UpdatedAt: 2023-04-20 18:10:36.578148693 +0000 UTC
  NextUpdate: 2023-04-21 00:10:36.578148393 +0000 UTC
  DownloadedAt: 2023-04-20 18:58:08.635511 +0000 UTC
Java DB:
  Version: 1
  UpdatedAt: 2023-03-14 00:47:02.774253754 +0000 UTC
  NextUpdate: 2023-03-17 00:47:02.774253254 +0000 UTC
  DownloadedAt: 2023-03-14 14:11:11.708775 +0000 UTC
Policy Bundle:
  Digest: sha256:d19c4c0d48ed4641862e020ff7eba7fd3ba449f66b532b09d79a6023bc65bd5b
  DownloadedAt: 2023-04-19 20:34:50.070035 +0000 UTC

Additional details (base image name, container registry info...):

Base image name: debian:11.6-slim
Container Registry: Dockerhub
Dockerhub Image

[falcantaralinode]

This gist has the full debugged json output of this command: trivy image debian:11.6-slim -f json --debug

[falcantaralinode]

It also be worth adding a flag where ignoring vulnerabilities if Debian considers a vulnerability to be a minor issue as another useful fix as well.

[falcantaralinode]

I would like to know where in the code is trivy going through the debian advisory initally. Parsing through the data in the initial stage could be an effective way to see if a vuln is considered minor and where the ignore minor vuln logic could be applied.

Scripting logic could be added like this:

Reading debian_advisory logic

If debian_advisory has no_dsa or minor_issue 
  then ignore

This could be applicable once trivy begins to read through the data source and it would be applicable for each and every format.

[knqyf263]

No field for that

[falcantaralinode]

No field in the data source or in the Debian trivy script itself? One idea could be to parse through the data source file and mark vulnerabilities as minor issues. The Debian data source itself has the text available: https://salsa.debian.org/security-tracker-team/security-tracker/-/blob/master/data/CVE/list#L387. One approach could be to parse the vulns looking for the text: "(Minor issue)" or "Minor Issue".

[knqyf263]

I meant we needed a field in Trivy DB to mark vulns as minor issues. But it is not a good idea to add a new field just for Debian.

[falcantaralinode]

Ok, I understand where you are coming from here. I take it that all of the distro tables have the same number of columns?
If they have the same number of columns, is there any way that we can still parse through the list and add a minor issue text in the title itself.

I was thinking of something like this:

if vuln_is_minor_issue:
  vuln_title + "| Debian Minor Issue"

[falcantaralinode]

Adding "Debian Minor Issues" in the title allows us to filter through vulnerabilities that have this text in the title itself. This can be expanded upon by adding the flag --ignore-debian-minor-issues where we can ignore debian minor issues if the vulnerability title has "Debian Minor Issue" in it.

If vuln_title has "Debian Minor Issue":
  ignore it

Additionally, this approach doesn't require a new field to be added in the trivy DB.

[hussamsh]

This is also causing problems for me as well. Our security team uses trivy as their main checker and CVE-8457 is showing as critical even though on Debian it is minor. The bigger problem is that libdb5.3 is an essential package and can't be removed or updated easily.

@falcantaralinode did you find a solution to this CVE?

[falcantaralinode]

No I wasn't able to find a solution currently. The only thing that I can think of is to simply ignore unfixed vulnerabilities so that way we get rid of all of the vulnerabilities while simply increasing the cadence of the scan as 1 way to approach this.

[a-poluyanov]

Our team is also experiencing issues when scanning Debian images.
Trivy finds libdb5.3 critical.
Please fix this, because Debian considers this a non-critical vulnerability.

[hlein]

I've been looking into this and some other issues Trivy flags.

Am I blind, or is there a worse problem here: Trivy is flagging on libdb5.3, but the description for CVE-2019-8457 is "SQLite3 from 3.6.0 to and including 3.27.2 is vulnerable to heap out-of-bound read in the rtreenode() function when handling invalid rtree tables."

What does libdb have to do with SQLite3? Nothing, as far as I can tell.

[hlein]

What does libdb have to do with SQLite3? Nothing, as far as I can tell.

Aha, except it does. Debian's libdb package included an embedded copy of sqlite3 supposedly, according to https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1010974

From that thread it seems that the bug was initially closed in error and then reopened; the first package version with the actual fix is 5.3.28+dfsg2-2.

[daneb255]

Any updates here? If trivy scan a debian 11 image, there are a lot of vulns shown. Mostly debian tagged the vulns as minor issue