False positive of CVE-2023-45853 on apt zlib1g/now 1:1.2.13.dfsg-1 package

[electronicapc]

I have a container from label studio reporting this vulnerability when I scan a label-studio docker image 1.15.0

zlib1g 1:1.2.13.dfsg-1 (won't fix) deb CVE-2023-45853 Critical

The CVE-2023-45853 report states that this vulnerability is for zlib specifically MiniZip which isn't present in the image.

`$ apt list -v | grep zlib

WARNING: apt does not have a stable CLI interface. Use with caution in scripts.

zlib1g/now 1:1.2.13.dfsg-1 amd64 [installed,local]`

I have no name!@2f64d5cd8f16:~$ dpkg -L zlib1g /. /lib /lib/x86_64-linux-gnu /lib/x86_64-linux-gnu/libz.so.1.2.13 /usr /usr/share /usr/share/doc /usr/share/doc/zlib1g /usr/share/doc/zlib1g/changelog.Debian.gz /usr/share/doc/zlib1g/changelog.gz /usr/share/doc/zlib1g/copyright /lib/x86_64-linux-gnu/libz.so.1

#https://nvd.nist.gov/vuln/detail/cve-2023-45853

[popey]

Hi @electronicapc - thanks for the issue.

I was able to reproduce this.

 $ syft heartexlabs/label-studio:1.15.0 -o syft-json=heartexlabs_label-studio_1.15.0.json
 ✔ Parsed image sha256:a0ad34dc284c8c5268eafcbbff06dce38fb6976a4b50f08f26f7fcc06f65dc45
 ✔ Cataloged contents aa6fe9ff0ae2a25803c33029f481193417d674d2d907a854255a2030cf52a083
   ├── ✔ Packages                        [323 packages]
   ├── ✔ File digests                    [3,900 files]
   ├── ✔ File metadata                   [3,900 locations]
   └── ✔ Executables                     [1,019 executables]

$ grype heartexlabs_label-studio_1.15.0.json -o json | grype explain --id CVE-2023-45853
[0000]  WARN grype explain is a prototype feature and is subject to change
 ✔ Vulnerability DB                [updated]
 ✔ Scanned for vulnerabilities     [126 vulnerability matches]
   ├── by severity: 1 critical, 6 high, 25 medium, 8 low, 80 negligible (6 unknown)
   └── by status:   6 fixed, 120 not-fixed, 0 ignored
CVE-2023-45853 from nvd:cpe (Critical)
MiniZip in zlib through 1.3 has an integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_64 via a long filename, comment, or extra field. NOTE: MiniZip is not a supported part of the zlib product. NOTE: pyminizip through 0.2.6 is also vulnerable because it bundles an affected zlib version, and exposes the applicable MiniZip code through its compress API.
Related vulnerabilities:
    - debian:distro:debian:12 CVE-2023-45853 (Critical)
Matched packages:
    - Package: zlib1g, version: 1:1.2.13.dfsg-1
      PURL: pkg:deb/debian/zlib1g@1%3A1.2.13.dfsg-1?arch=amd64&distro=debian-12&upstream=zlib
      Match explanation(s):
          - debian:distro:debian:12:CVE-2023-45853 Indirect match; this CVE is reported against zlib (version 1:1.2.13.dfsg-1), the origin of this deb package.
      Locations:
          - /usr/share/doc/zlib1g/copyright
          - /var/lib/dpkg/info/zlib1g:amd64.md5sums
          - /var/lib/dpkg/status
URLs:
    - https://nvd.nist.gov/vuln/detail/CVE-2023-45853
    - https://security-tracker.debian.org/tracker/CVE-2023-45853
    - 

Issue CVE-2023-45853 comes up quite a bit. Here is a comment we have posted previously about this issue.

[spiffcs]

Also useful for this issue is this thread which talks about how the link between minizip and zlib are correlated (probably incorrectly):

madler/zlib#868 (comment)

I think there might be something grype can do about these kinds of cases, but defer to @westonsteimel or @joshbressers for a comment before we discuss how to deal with these kinds of FP.

[joshbressers]

The challenge for this one is Debian lists the zlib package as vulnerable
https://security-tracker.debian.org/tracker/CVE-2023-45853

The reason being the zlib source is technically vulnerable. I'll let @westonsteimel weigh in if he thinks there's something we can do here

[westonsteimel]

No, nothing we can do at the moment really since we do not currently have any capablity for overriding a distro data source. We added a hack in vunnel to change the severity that will be calculated on some entries, but no way to make it not show up at all. The issue as always with many of the distro feeds is that the vulns are specified at the source level rather than at the package level so there are always some FPs due to this. Would I like to address this at some point by curating our own dataset? Most certainly, but we can currently only just about keep up with the barage of data coming from CVE/NVD so won't be able to take on curating distro data just yet

[joshbressers]

@westonsteimel @spiffcs I wonder if the discussion should be around how to make small changes to some of our data (not a full on feed, just a few nitpicky changes)

I can think of a few instances where the distros were "technically correct" but created pain for Grype users. Generally speaking the distro data is really good. The same is even true of GitHub where we've asked for some minor changes that were rejected, but those minor changes would help out Grype users.

CVE is a different story because it needs so much work to fix the problems, so I would treat what we currently do there as outside this scope

These are cases where being able to make minor changes to the fields we collect could make a difference. I can think of at least one instance where we hard coded such a fix into vunnel, I'm sure there are others.

[westonsteimel]

I think you underestimate how diifficult that becomes. @willmurphyscode put some significant effort into this (prior to the NVD meltdown) and realised how much work it was and we ended up having to move onto other things and have never made it back to it: anchore/vunnel#417. There are hard-coded explicit ignores in grype which can be utilised if we really don't want something showing for any grype user

[westonsteimel]

What I would like to see in the future is all of the data from upstream providers flowing into a public git repo with each file being in a format that is simpler for human curators to understand, then grype would compile its data from that, but we aren't ready for that yet

[joshbressers]

I do recall the work @willmurphyscode did now that you mention it

OK, so ignore my comment :)

In the meantime should we consider hardcoding something for this one? I think we can make reasonable arguments in both directions