Please release 1.3.1 to fix CVE-2023-45853 (9.8 CRITICAL)

[304NotModified]

@madler

It looks like the fix is already in develop: See #843 and 73331a6

We only new a new release :)

See also: https://nvd.nist.gov/vuln/detail/CVE-2023-45853

[Neustradamus]

@madler: Can you do it?

Thanks in advance.

[Neustradamus]

Linked to:

• https://github.com/search?q=CVE-2023-45853&type=issues
• https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290
• https://www.google.com/search?q=CVE-2023-45853
• ...

cc: @gvollant, @madler.

[mplotkin-clr]

Any expected timeline for a fix for CVE-2023-45853?

[madler]

I may put out a release soon, but please note that minizip is not part of zlib. The source code is provided in the contrib directory of the zlib distribution, along with several other such contributions, as a courtesy. This is not a zlib vulnerability.

[theroch]

I may put out a release soon, but please note that minizip is not part of zlib. The source code is provided in the contrib directory of the zlib distribution, along with several other such contributions, as a courtesy. This is not a zlib vulnerability.

Sure, but the problem is, that zlib is bundled with minizip in most of the linux distributions (Ubuntu, Debian ...).
So the zlib package is affected by this CVE and is marked as critical by the vulnerability scanners like Trivia.
In our case, it is currently not possible to deploy a Docker image because Trivia and our customers' security policies prohibit deployment due to the critical CVE it contains.

So can you please release 1.3.1 with the fix?

[Neustradamus]

@madler: I think that you can create a GitHub organization for zlib, and move contrib in external repository, it will be better to manage :)

[hannes-ucsc]

In the Debian package, the source code to minizip is bundled as the /usr/share/doc/zlib1g-dev/examples/minigzip.c. Why is the presence of a source code file, from which a vulnerable binary must first be compiled and linked before the vulnerability becomes exploitable, considered of critical severity?

[broonie]

For whatever reason we also ship a binary of minizip as a separate package, and there's some other packages have copied the source.

[ymTm7KuhCnIjkZAl2x2m2]

If you have something that ships a broken minizip, take it up with them

That's literally what we're doing here. zlib ships a broken minizip.

[NiKiZe]

If you have something that ships a broken minizip, take it up with them

That's literally what we're doing here. zlib ships a broken minizip.

Nope, zlib contains a contrib directory.

Since when did a contrib directory start being "part of" a package? I seem to have missed that announcement.

[ymTm7KuhCnIjkZAl2x2m2]

Nope, zlib contains a contrib directory.

Go to zlib.net, download the first link under "The current release is publicly available here:". This is what zlib SHIPS, this is the deliverable that everybody who downloads zlib gets. This contains the vulnerable code. Therefore it is exactly:

... something that ships a broken minizip

But @orbatec said it best

It's a shame that 3 months later we are still having ideological discussions for something that is altogether not very hard to resolve

[NiKiZe]

Nope, zlib contains a contrib directory.

Go to zlib.net, download the first link under "The current release is publicly available here:". This is what zlib SHIPS, this is the deliverable that everybody who downloads zlib gets. This contains the vulnerable code. Therefore it is exactly:

I might be wrong...
Does it build with a default make? Is it in a directory not marked as contrib, does it define contrib as part of the package?

But @orbatec said it best

It's a shame that 3 months later we are still having ideological discussions for something that is altogether not very hard to resolve

Agreed, mark the CVE as invalid, as it should be, done, no release needed.

[broonie]

minizip is not built as part of the default zlib, however as discussed much earlier it is built and shipped as a separate binary package by some distros which means the source package for zlib ends up having an issue even though the binaries with zlib itself are fine.

[NiKiZe]

minizip is not built as part of the default zlib, however as discussed much earlier it is built and shipped as a separate binary package by some distros which means the source package for zlib ends up having an issue even though the binaries with zlib itself are fine.

Those distros is the ones with problems, not zlib.

[ymTm7KuhCnIjkZAl2x2m2]

I might be wrong...
Does it build with a default make? Is it in a directory not marked as contrib, does it define contrib as part of the package?

If you go to the page and download the deliverable, you have the vulnerable code. It doesn't matter if you "define" it differently. The fact is, the thing you've downloaded IS zlib for all intents and purposes. If you don't want to be responsible for something, don't deliver it.

The CVE is accurate. I'm sorry you don't want to hear this.

[NiKiZe]

I might be wrong...
Does it build with a default make? Is it in a directory not marked as contrib, does it define contrib as part of the package?

If you go to the page and download the deliverable, you have the vulnerable code. It doesn't matter if you "define" it differently. The fact is, the thing you've downloaded IS zlib for all intents and purposes. If you don't want to be responsible for something, don't deliver it.

The CVE is accurate. I'm sorry you don't want to hear this.

I don't really care about zlib, but I do see CVE system as broken due to abuse.

The fact is still that contrib is not something that should be used, and especially not packaged (read distributed in a form meant for installation), without the one doing so taking responsibility.

Every instance we see here about zlib being marked as vulnerable in systems not even having minizip is proof of the CVE being invalid. If anyone cared they would mark minizip as vulnerable, not zlib.
Why would these, actually used packages, be updated with ABSOLUTELY NO CHANGE just to have the invalid CVE flag dropped?

The broken CVE system needs to be fixed. Not non broken packages.

[hannes-ucsc]

If the minizip source from this repository is compiled by a distributor and the resulting binary is included in a binary package for zlib, then it should be up to them to come up with a means to incorporate the fix without requiring a release of zlib, as including sources from a contrib directory is not commonly done (I am happy to be proven wrong on this assertion).

If there are no binary packages named zlib that include the compiled minizip source, then attributing a severity of CRITICAL to a CVE for zlib is unjustified as no system on which such a zlib binary package is installed is immediately vulnerable.

If there are binary packages labelled minizip that include the result of compiling the minizip source from this repository, then the CVE model should accommodate that, and vulnerability scanners should support that model, so that users aren't forced into action unless they actually installed the minizip package.

Lastly, vulnerability scanners should not rely on package installation metadata to determine if a system is vulnerable, but instead on binary signatures, just like malware scanners.

[leberknecht]

I think this discussion has lost focus... No one says that the maintainer has to release a fix, it just would be very very helpful for a lot of people, despite the fact that it might or might not be a good idea for a packaging systems to compile things from contrib folder. When people claim that it is very good that its broken so people feel the pain of problems that CVE scanners brings and so on, i think that discussion belongs somewhere else (not exactly sure where though)... ❤️

[hannes-ucsc]

Out of curiosity, which binary zlib package includes the result of compiling the minizip source from the contrib directory of this repository? I've only come accross the uncompiled source in the zlib1g-dev Debian package.

[broonie]

In unstable the zlib source package in Debian (and derivatives that don't change this) also builds minizip and libminizip binary packages using what's in contrib (minzip does have some direct users). eg, https://packages.debian.org/sid/minizip

[hannes-ucsc]

So the CVE should be only be attributed, at least with CRITICAL severity, to the libminizip binary package, and maybe with moderate priority to any other packages that include the source. Does the conceptual model underneath CVEs support assigning different severities to individual packages, or package types (source vs binary)? Or could two CVEs have been created, a critical one for minizip and a moderate one for zlib?

[broonie]

AFAICT (certainly here) they just track the source.

[mswilson]

The CVE system itself is not designed to attribute a given vulnerability to a package. Its purpose is only to give a specific publicly known vulnerability a common identifier. Nothing more. CPE is a component of the CVE ecosystem that can be used to enumerate software and configurations that may embody a publicly known vulnerability.

There is a CPE for minizip, and at least one CVE refers to CPE records with minizip as a named software package: CVE-2014-9485.

Unfortunately this is an example of the systemic problems we're dealing with when the canonical upstream for a given piece of code is unclear, and information is lost: Debian patched their minizip packaging, but the copy of minizip source code that is present in the zlib source distribution does not have this fix.

msw@carbon:~/git/zlib/contrib/minizip$ git rev-parse HEAD
36e369e1a54b35a978dc584496af69a07ec2d71a
msw@carbon:~/git/zlib/contrib/minizip$ ls /tmp/moo 
ls: cannot access '/tmp/moo': No such file or directory
msw@carbon:~/git/zlib/contrib/minizip$ ./miniunz ~/Downloads/traversal.zip 
MiniUnz 1.1, demo of zLib + Unz package written by Gilles Vollant
more info at http://www.winimage.com/zLibDll/unzip.html

/home/msw/Downloads/traversal.zip opened
 extracting: /tmp/moo
msw@carbon:~/git/zlib/contrib/minizip$ ls /tmp/moo 
/tmp/moo

The way that CVE and CPE are designed for security and software development practitioners, it would be appropriate to tag the source code distribution of zlib as containing this publicly known vulnerability, along with Chromium as it has a vulnerable copy of the source code, and anywhere else there's a copy of the vulnerable source code. This enriches the information that the CVE system is able to provide to the broader development community, and can help ensure that fixes to code that has been copied are propagated to other copies.

Unfortunately, CVEs have taken a life of their own for software users (consumers), and this introduces downsides in its adoption for software producers. As soon as the zlib source distribution gets tagged with a CVE, it is assumed that downstream redistributors are passing a vulnerability in zlib itself on to end-user consumers, even if a compiled libz binary that can be put into service does not in any way contain that vulnerability.

Software users have to scurry to apply updates that are effectively no-ops, sometimes under extreme time pressure when the NVD has a 9.8 CVSSv3 score for a given CVE. And when there's no new source code version released that satisfies the CPE pattern matcher (so that the scan report comes back green), end-users come knocking on the door of maintainers that are volunteering their own time to make new releases.

In any case, upon discovery of this non-upstream'ed fix in Debian's packaging of minizip, I will open a separate issue to track integrating the fix from Debian into the copy distributed with zlib source code.

How this slipped by "ZipSlip", I have no idea.

[Neustradamus]

Zlib 1.3.1 has been released (2024-01-22):

• https://github.com/madler/zlib/releases/tag/v1.3.1
• https://zlib.net/

Thanks @madler.

[ringerc]

For anyone coming here due to https://security-tracker.debian.org/tracker/CVE-2023-45853 for Debian Bookworm (12) or Bullseye (11) and the zlib source package versions 1:1.2.13.dfsg-1 or 1:1.2.11.dfsg-2+deb11u2 which are listed as vulnerable there, and in 3rd party trackers like https://security.snyk.io/vuln/SNYK-DEBIAN12-ZLIB-6008963:

You should note this wording in the Debian advisory:

[bookworm] - zlib (contrib/minizip not built and src:zlib not producing binary packages)
[...]
src:zlib only starts building minizip starting in 1:1.2.13.dfsg-2. For older suites due to this an update can be ignored as no binary package built by the vulnerable source is affected (i.e. contrib/minizip not built and provided in those versions).

Based on this and the Debian package sources, it appears that there is a Debian-patched version of the sources for minizip in the source archive for the zlib source package version 1:1.2.13.dfsg-1 and 1:1.2.11.dfsg-2+deb11u2 that has the code this CVE relates to. But these sources are not built or included in any binary package. There is therefore no issue for binaries built against these versions of the zlib libraries, container images using these source package versions etc.

See:

• https://packages.debian.org/source/bookworm/zlib
• http://deb.debian.org/debian/pool/main/z/zlib/zlib_1.2.13.dfsg-1.dsc
• http://deb.debian.org/debian/pool/main/z/zlib/zlib_1.2.13.dfsg.orig.tar.bz2
• http://deb.debian.org/debian/pool/main/z/zlib/zlib_1.2.13.dfsg-1.debian.tar.xz

I think scanners are flagging this because of logic like:

• zlib1g (or other binary packages from that source package) version 1:1.2.13.dfsg-1 is installed
• its source package is zlib
• so check vuln scan results for source package zlib version 1:1.2.13.dfsg-1
• The code relating to CVE-2023-45853 is present in this source package, so it could potentially have been delivered in binaries built from this source package
• ... therefore, flag zlib1g as vulnerable.

It's simplistic, but makes some sense. In this case it's also wrong, there is no problem here.

So as far as I can tell, there is no fix for the Debian CVE because no actual vulnerability exists. Nobody's likely to make a backport package to delete the unused sources to silence scanners that aren't smart enough to detect the actual presence of the vulnerability in a shipping binary or container image.

Check your /var/lib/dpkg/status.d/zlib1g (or other packages with zlib as a source package) metadata for the Debian version against 1:1.2.13.dfsg-2 with dpkg --compare-versions, e.g.:

$ MY_VERSION=$(awk '/^Version:/ { print $2}' var/lib/dpkg/status.d/zlib1g)
$ echo "${MY_VERSION}"
1:1.2.13.dfsg-1
$ if dpkg --compare-versions "${MY_VERSION:?missing MY_VERSION}" lt 1:1.2.13.dfsg-2; then echo "$MY_VERSION is older than the first vulnerable version"; else echo "$MY_VERSION is potentially vulnerable"; fi

1:1.2.13.dfsg-1 is older than the first vulnerable version

I have raised this to Snyk as case 500PU00000UkHkXYAV

[Neustradamus]

@ringerc: 1.3.1 version has been released 2024-01-22:

• Please release 1.3.1 to fix CVE-2023-45853 (9.8 CRITICAL) #868 (comment)

[ringerc]

@Neustradamus I know, thanks. I'm trying to help folks who trip over the false positive from Snyk about this on Debian 12.

[ecki]

Just for completeness, many of those broken Scanners would not even Look at the (patches) source, just based on CPE, so deleting it would not help.

But it’s strange that (Manila) Snyk does not overwrite the Scan results. They (and Docker Scout) cause quite some extra work formPSIRT to explaining such false detections in vendor Containers.