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.

[ekomarova]

Yes, BDBA identifies the conda-forge zlib packageas vulnerable. But I could assume that in fact BDBA scan is not very smart and just compares the product version with the vulnerabilities from NVD database and it doesn't actually scan the bits themselves. Therefore, it would be great to get confirmation that, for example, the package created by conda-forge may not actually even contain this vulnerability since it doesn't content minizip bits inside

[hannes-ucsc]

@ekomarova, @mswilson would you mind taking the discussion to conda-forge? I believe you are slightly off-topic. This issue is about creating a zlib release that includes the fix for the vulnerability, as the vulnerability has already been addressed on the develop branch of this repository.

[Neustradamus]

Do not forget that minizip is included in zlib, it is for this, a lot of people ask a new release build.

[NiKiZe]

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

The CVE should just be closed as invalid since it has nothing to do with zlib.

[orbatec]

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 it is not a zlib issue
• but it is in minizip which is in contrib which is shipped with zlib : historically wrong decision, maybe, but that is irrelevant; fact is that it just is like this now
• linux distro's pick up zlib and pull in the contrib => scanners report the issue
• CVE is not likely going to be closed or invalidated for zlib anytime soon

Why is the mere fact that the contrib content has changed not enough to create a new release? I get that no real change in zlib would be included in this release...but just a minor release to accommodate for the contrib change...doesn't sound like a big ask.

I tried working around the issue too. One would think that it should be trivial to write a Dockerfile that replaces the pulled in zlib from the base image with a self-built version based on the develop branch...but I was surprised to see there is literally no documentation on how to do this. I could not find anyone to give me useful info here either so did some trial an error myself with my limited knowledge...but no success...

I am ignoring the vulnerability scanner for now, but our biggest corporate sponsor is not liking it at all...

[NiKiZe]

Why would you replace a zlib that isnt affected?
There is several examples where minizip isn't even used but zlib marked as vulnerable. That is purely invalid.

It is good that this isn't released because it shows how fundamentaly broken current CVE system has become, and how it over and over again is abused. As another example, take a look at curl and all invalid CVEs it has to fight.

If you have something that ships a broken minizip, take it up with them (they shouldn't be shipping anything as compiled from a contrib directory).
And if you only have zlib then the CVE is invalid, mark it as such. If whatever you are using don't have support for marking it as invalid, it's time they implement that feature.

The only ridiculous thing here is the amount of people that think a invalid CVE is something that needs to be resolved by a release.

[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.