search

madler / zlib

A massively spiffy yet delicately unobtrusive compression library.
http://zlib.net/
Other
5.58k stars 2.43k forks source link

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

Closed 304NotModified closed 7 months ago

304NotModified commented 10 months ago

@madler

It looks like the fix is already in develop: See https://github.com/madler/zlib/pull/843 and https://github.com/madler/zlib/commit/73331a6a0481067628f065ffe87bb1d8f787d10c

We only new a new release :)

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

Neustradamus commented 10 months ago

@madler: Can you do it?

Thanks in advance.

Neustradamus commented 10 months ago

Linked to:

cc: @gvollant, @madler.

mplotkin-clr commented 10 months ago

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

madler commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

@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 commented 10 months ago

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 commented 10 months ago

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

hannes-ucsc commented 10 months ago

The CVE should then be assigned to that package, not zlib, no?

broonie commented 10 months ago

The CVE is assigned to the source package from which all the binary packages are built.

hannes-ucsc commented 10 months ago

Got it. My vulnerability scanner (Docker Desktop) flags debian/zlib 1:1.2.11.dfsg-2+deb11u2 as vulnerable to that CVE, even if I manually remove /usr/share/doc/zlib1g-dev/examples/minigzip.c from the image, but I guess that's a bug in Docker Desktop.

theroch commented 10 months ago

Got it. My vulnerability scanner (Docker Desktop) flags debian/zlib 1:1.2.11.dfsg-2+deb11u2 as vulnerable to that CVE, even if I manually remove /usr/share/doc/zlib1g-dev/examples/minigzip.c from the image, but I guess that's a bug in Docker Desktop.

@hannes-ucsc The scanners do not work like this. The scanners use a database containing vulnerable packages with the affected version numbers. Scanning is based on this catalog. If a package with a correspondingly vulnerable version is found, a message is issued. It does not matter whether you have compiled the package manually and perhaps patched it. Most of the databases are base of the information from NIST.

304NotModified commented 10 months ago

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.

Is there an ETA for the release?

Neustradamus commented 10 months ago

@madler: I have sent you an email, important, thanks in advance.

gpchandran commented 10 months ago

@madler - thanks for fixing this issue, any ETA for patch or any workaround to remediate this issue. CVE-2023-45853

frispete commented 10 months ago

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.

Understood.

Note, that a new release will fix quite a number of build issues automagically, that still expect a 3 element version of zlib everywhere (most notably cmake, again).

Neustradamus commented 10 months ago

@frispete: It is not zlib but it is included with it. I have sent an email to @madler with a solution, I have not received answer yet...

orbatec commented 10 months ago

This is not a zlib vulnerability

@madler : I do appreciate this, but like someone else mentioned, it is bundled with minizip in most distros which is a problem.

So for us also our security scanner is flagging zlib as having a Critical, and without new release of zlib, there is also no new release of our AmazonCorretto linux base image, and hence we are stuck with the Critical and our SLA goes to sh*t. I mostly blame Docker hub for this as their vulnerability scanner is **** listing the corretto image we are using as completely free of vulnerabilities while other scanners (like AWS) find a critical and 4 High... go figure...

If a new release is a small effort on your part, it will be a huge relief for many of us that indirectly rely on it.

salman-moh commented 10 months ago

Is there an ETA for the release @madler ? Even a rough estimate would help understand timelines for people who have applications running in QA and PROD.

Thanks in advance!

spdw commented 10 months ago

In the minizip header files different minizip version numbers are mentioned.

Do you plan to update the minizip version information?

gvollant commented 10 months ago

updating to 1.2 is a good idea

Neustradamus commented 10 months ago

@gvollant: Can you look your emails and tickets? Several months without an answer... Thanks in advance.

mswilson commented 10 months ago

@orbatec said:

@madler : I do appreciate this, but like someone else mentioned, it is bundled with minizip in most distros which is a problem.

So for us also our security scanner is flagging zlib as having a Critical, and without new release of zlib, there is also no new release of our AmazonCorretto linux base image, and hence we are stuck with the Critical and our SLA goes to sh*t. I mostly blame Docker hub for this as their vulnerability scanner is **** listing the corretto image we are using as completely free of vulnerabilities while other scanners (like AWS) find a critical and 4 High... go figure...

If a new release is a small effort on your part, it will be a huge relief for many of us that indirectly rely on it.

I'm not sure if you're at Amazon or elsewhere. If you're at Amazon, please reach out to me on Slack (msw@) so I can understand what you're seeing better.

If not, I'd still like to know which "AWS scanner" is triggering a false alarm. It is well understood that the code associated with the CVE is not part of zlib itself, and that needs to be corrected.

salman-moh commented 10 months ago

Kinda surprised this isnt getting more voice, have people found a workaround by deleting MiniZip from zlib? I totally understand fixing this takes time and respect the authors; but I had to ask, I use the python slim base image from DockerHub, and I havent found a solution to it, certainly doesnt help to go to production environment.

mswilson commented 10 months ago

Deleting source code from a package won't fix bad metadata in vulnerability databases.

https://nvd.nist.gov/vuln/detail/CVE-2023-45853 has a CPE of cpe:2.3:a:zlib:zlib:*:*:*:*:*:*:*:*, meaning all versions of the "zlib" package will get tagged as "affected" by a scanner that only operates at a shallow "package version" level of inspection.

I think that the Debian developers know what's what, and that only their "minizip" and "libminizip-dev" packages (and packages that depend on it), and additional software packages that have "vendored" the MiniZip code are affected. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290

salman-moh commented 10 months ago

Well these scanners usually are not fully upto date with NVD. So I dont think we can blame them, I assume he is talking about the Scan within ECR -elastic container registry, not sure what software is used when you scan there. @mswilson

mswilson commented 10 months ago

The NVD as it sits today has metadata in it that will erronously tag zlib packages as vulnerable. It isn't a problem with scanners not being up to date.

orbatec commented 10 months ago

@mswilson I'll get in touch on Slack on Monday. We are on AWS with AWS Inspector scanning our images (not sure what is the underlying tech). We also pointed our Aikido vulnerability scanner (aikido.dev) directly to the amazoncorretto:21.0.1-al2023 image on Docker hub. It seems to come up with the same report as the AWS Inspector.

I'm no expert in Docker images, or linux for that matter...I am just trying to get rid of reported Criticals and Highs for my services. If they are false positives I am very interested in trying to understand how we can then somehow educate our scanning tool better so that it picks up on this.

I do hear you when you say that it is not really a zlib issue...

salman-moh commented 10 months ago

I'm just saying different scanners show different vulnerabilities levels like one might show 1 critical 4 high 24 medium, other might show 1 critical 12 high 16 medium. I dont think the scanning tool can smartly identify false positives, we need a release of zlib or maybe if zlib wants to get rid of MiniZip? idk

orbatec commented 10 months ago

@mswilson What I do not understand is that @madler did create a patch for this "vulnerability" that is "not a zlib vulnerability"... so what about that? Way I understand this, is that zlib depends on another library (minizip) which contains a vulnerability. The underlying base linux image (alpine 3.17 in my case) has the latest zlib release in it... this is the release where zlib uses the faulty minizip... the patch of zlib was done about 4 weeks ago now. But as no release is made, there is also no trigger to create a new linux release.... at least that is how I understood it. But I can be wrong...I do not claim to be an expert! I come from a Java background.... to me this sounds like zlib has a dependency on minizip and bundles it in its library, instead of declaring the dependency as "provided" and letting the users of zlib handle providing the dependency.

And now I will shut up before I make a complete fool of myself :-D

tbeu commented 10 months ago

updating to 1.2 is a good idea

According to configure.ac it already is at 1.3 and tight to the zlib version.

https://github.com/madler/zlib/blob/643e17b7498d12ab8d15565662880579692f769d/contrib/minizip/configure.ac#L4

1.2 already seems taken, see

https://github.com/zlib-ng/minizip-ng/blob/ef3ef9a4b8319b94d174d8911404a8b98d319ac7/README.md#L18

tbeu commented 10 months ago

Way I understand this, is that zlib depends on another library (minizip) which contains a vulnerability.

No, it is the other way round. Minizip depends on zlib.

mswilson commented 10 months ago

@orbatec said:

@mswilson What I do not understand is that @madler did create a patch for this "vulnerability" that is "not a zlib vulnerability"... so what about that? Way I understand this, is that zlib depends on another library (minizip) which contains a vulnerability.

That is not correct. minizip is additional community-contributed code in the contrib/ directory that can be used in conjunction with the functionality that comes from zlib.

Some Linux distributions (like Amazon Linux) package up a shared library utility that MiniZip provides (e.g., the minizip package in Amazon Linux), along with a development package (e.g., minizip-devel). But nothing in Amazon Linux actually uses the minizip library that is built out of the zlib sources.

Nevertheless, the "zlib" package gets tagged as "affected by" this CVE in update metadata, and scanners that only key off of package names as they are found in CPE entries of vulnerability databases will sound false alarms.

mswilson commented 10 months ago

I'm just saying different scanners show different vulnerabilities levels like one might show 1 critical 4 high 24 medium, other might show 1 critical 12 high 16 medium. I dont think the scanning tool can smartly identify false positives, we need a release of zlib or maybe if zlib wants to get rid of MiniZip? idk

None of that will address the situation as it stands today, with scanners that are currently in use, for the CVE that is under discussion here.

Scanners are going to trigger false alarms in scenarios such as this one because that's how the vulnerability database and scanner ecosystem is today.

Rushing an upstream open source maintainer to do a release to silence a scanner is the wrong way to fix the problem, in my personal opinion.

ymTm7KuhCnIjkZAl2x2m2 commented 9 months ago

I don't understand how the scanner is doing anything wrong. If I download zlib from your website, I have downloaded the vulnerable code. You're not rushing a release to silence a scanner; you're rushing a release to fix a CVE. Though I'm not really sure it's rushed at this point.

mswilson commented 9 months ago

I don't know how to say it any more plainly than this: the central function of vulnerability scanners that inspect deployable software contents is to detect legitimate vulnerabilities in those binaries. If a scanner is only looking at package metadata in an image, determining that "zlib = 1.3.0" is present in the image, and it reports "this image is vulnerable to CVE-2023-45853 (9.8 CRITICAL)", it is almost certainly wrong.

304NotModified commented 9 months ago

Hi all,

This GitHub issue is requesting a patch release.

If you like to discuss if this is or isn't needed, or how scanners work, or other off topic topics ;) please do that in another Github issue. Thanks!

Neustradamus commented 9 months ago

I have given a solution to @madler, I hope that he looks emails...

NiKiZe commented 9 months ago

So buggy security scanners and databases makes people think that a release is required? The fix is to have the CVE record corrected. Reading the comments here it is mind lowing to see how simple minded so many are.

Providing example code should NEVER trigger a CVE for the actual code. WTF!

madler commented 9 months ago

What I do not understand is that @madler did create a patch for this "vulnerability" that is "not a zlib vulnerability"... so what about that?

@zmodem (Hans) submitted a patch to address the issue, and I committed it. I'm missing what, exactly, is difficult to understand there. Are you saying that the stuff in the contrib folder should never be altered?

Neustradamus commented 9 months ago

@madler: Your email address is madler@alumni.caltech.edu or not? I have sent you the best solution in an email, can you do it?

theroch commented 9 months ago

Yesterday a patch for debian SID was relased. We can therefore assume that the patch for other versions and Ubuntu will follow next week.

https://security-tracker.debian.org/tracker/CVE-2023-45853 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1054290 https://ubuntu.com/security/CVE-2023-45853

salman-moh commented 9 months ago

How come we cant just move to that version with a nonSID debian? Also, a fix in zlib means a fix in MiniZip? I see they list vulnerability for MiniZip and zlib separate, the debian website.

broonie commented 9 months ago

I wouldn't assume a timeline for non-sid releases (other than testing) - stable and oldstable are managed through a completely different process by different people.

orbatec commented 9 months ago

The NVD as it sits today has metadata in it that will erronously tag zlib packages as vulnerable. It isn't a problem with scanners not being up to date.

What I do not understand is that @madler did create a patch for this "vulnerability" that is "not a zlib vulnerability"... so what about that?

@zmodem (Hans) submitted a patch to address the issue, and I committed it. I'm missing what, exactly, is difficult to understand there. Are you saying that the stuff in the contrib folder should never be altered?

That is not what I was saying...I was saying I did not understand that something needed patching when in fact there is no vulnerability.... asking questions is how I learn... sorry if that is offensive. I understand now that zlib is a base, and minizip is using zlib. I also understood that minizip is maintained by someone else. And I understand that minizip is bundled with zlib in the /contrib folder. But I also looked at the code and see that the validation was idd lacking which is now addressed...so the scanners were not wrong. Yes, they probably should have mentioned minizip instead of zlib, but if I sell a camera and I include a flash that I did not build myself, the customer is still gonna look to me for a solution...

But glad it is resolved ...

madler commented 9 months ago

I did not say there is no vulnerability. I said that there is no zlib vulnerability. The stuff in contrib is not part of zlib. It is provided in the source distribution only as a courtesy (as explained the comment you referenced), which was perhaps an egregious error. minizip is not a flash bulb. It is a user of the camera. There could be a whole undiscovered country of vulnerabilities in the contrib directories, but it does not matter to zlib, as none of it is needed for zlib. Lastly, nothing is being sold here. I have been paid exactly zero dollars and zero cents for co-authoring and maintaining zlib for almost 30 years now. Which is fine.

Neustradamus commented 9 months ago

@madler: The solution is to have a repository for zlib and another one for contrib here:

hannes-ucsc commented 9 months ago

… or for distributors to stop including the files from the contrib directory in their packages?

NiKiZe commented 9 months ago

One question, if there vuln in a contrib parts, which is kind of documentation. How would an error in examples in documentation/manpage be handled? Which is the same thing, would that demand a release as well? No!

Mr-Clam commented 9 months ago

One question, if there vuln in a contrib parts, which is kind of documentation. How would an error in examples in documentation/manpage be handled? Which is the same thing, would that demand a release as well? No!

I think it should demand a release because people copy and paste example code. In a way, it's worse because it can proliferate further and nobody (e.g. scanners) is specifically looking for it when an error occurs.