minizip: Check length of comment, filename, and extra field, in zipOpenNewFileInZip4_64

zmodem commented 1 year ago

These are stored in 16-bit fields in the zip file format. Passing longer values would generate an invalid file.

Passing very long values could also cause the computation of zi->ci.size_centralheader to overflow, which would cause heap buffer overflow on subsequent writes to zi->ci.central_header.

This was reported to Chromium in https://crbug.com/1470539, and patched in https://crrev.com/1182507 and https://crrev.com/1182669

madler commented 1 year ago

Applied.

Neustradamus commented 1 year ago

@zmodem, @madler: Can you look @irwir comments here:

https://github.com/madler/zlib/commit/73331a6a0481067628f065ffe87bb1d8f787d10c

ljavorsk commented 1 year ago

Hi, @madler does this affect the versions prior to 1.3 as well?

ljavorsk commented 1 year ago

Also the CVE-2023-45853 has been assigned to this bug

Persi commented 1 year ago

@madler The above mentioned CVE is ranked with high criticality. As the fix already is in delelop branch, could you please provide a new patch release 1.3.1 of this lib?

Neustradamus commented 1 year ago

@madler: Can you look?

rossburton commented 1 year ago

For anyone looking for the integrated patch, it's https://github.com/madler/zlib/commit/73331a6a0481067628f065ffe87bb1d8f787d10c.

Neustradamus commented 1 year ago

@rossburton: Yes it is in "develop" branch, not in a stable build.

rvoliveti-cpu commented 11 months ago

Hi, @madler does this affect the versions prior to 1.3 as well for example version 1.2.12?

aiakubovich commented 11 months ago

@madler @zmodem

I have pipeline that has to use Aqua Scan and I started to get critical vulnerability for version 1:1.2.13.dfsg-1. Here is reference to report: https://security-tracker.debian.org/tracker/CVE-2023-45853. Could you please look at it?

yaayes commented 11 months ago

@madler could you please release a patch ?

svadnala commented 11 months ago

@madler @zmodem

I have pipeline that has to use Aqua Scan and I started to get critical vulnerability for version 1:1.2.13.dfsg-1. Here is reference to report: https://security-tracker.debian.org/tracker/CVE-2023-45853. Could you please look at it?

Similar issue, are there any instructions to get this patch while awaiting to be included as part of debian package repository 1.3?

cgargas commented 11 months ago

@madler @zmodem I have pipeline that has to use Aqua Scan and I started to get critical vulnerability for version 1:1.2.13.dfsg-1. Here is reference to report: https://security-tracker.debian.org/tracker/CVE-2023-45853. Could you please look at it?

Similar issue, are there any instructions to get this patch while awaiting to be included as part of debian package repository 1.3?

Running into same issue with the vulnerability being flagged via a scan. Any updates as to when this fix will be merged into the master branch?

yashpct2807 commented 11 months ago

Running into same issue with the vulnerability being flagged via a scan. Any updates on this stable release?

Neustradamus commented 9 months ago

Merged commit:

https://github.com/madler/zlib/commit/73331a6a0481067628f065ffe87bb1d8f787d10c

Neustradamus commented 9 months ago

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

DarrenJAN commented 8 months ago

I am not sure why it still shows the vulnerability when I upgraded zlib from 1.2.13 to 1.3.1..... Did anyone do the scan?

madler commented 8 months ago

I am not sure why it still shows the vulnerability

What is "it"?

raghu298 commented 7 months ago

I am not sure why it still shows the vulnerability when I upgraded zlib from 1.2.13 to 1.3.1..... Did anyone do the scan?

How you upgraded actually i have a python:3.11.8-slim image build from debain image has "InstalledVersion": "1:1.2.13.dfsg-1" zlib1g.

I want to upgrade to higher version.

Tried apt upgrade zlib1g but that didnot help?

raghu298 commented 7 months ago

@madler Can you help in fix the issue?

madler commented 7 months ago

@madler Can you help in fix the issue?

I don't see how. zlib was fixed. There's nothing more I can do after that.

I am not sure why it still shows the vulnerability

What is the "it" that is saying that there is a vulnerability?

DarrenJAN commented 7 months ago

By palamida scan, it showed that there are vulnerability on the identical files during this upgrade. It is the palamida bug.

raghu298 commented 7 months ago

@madler: VulnerabilityID": "CVE-2023-45853", "Title": "zlib: integer overflow and resultant heap-based buffer overflow in zipOpenNewFileInZip4_6", "Description": "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.",

This is the vulnerability and its occurring in python:3.11.8 image as built on debain 12 image. Is there a way to upgrade to 1.3.1 which is not vulenarble?

madler commented 7 months ago

@raghu298 You are still not telling me what "it" is that is saying that. I don't need to know the message. I want to know who the messenger is. What, exactly, is reporting this? Are you running something to tell you this?

What do you mean that it is "occurring in python:3.11.8 image"? Are you scanning the Python executable? Are you running Python code? What are you doing to incite the message?

raghu298 commented 7 months ago

@madler I have trivy image scan tool which scans the image and shows the vulnerabilities. I am using python 3.11.8-slim image which is built on top of debian image and that has zlib1g "InstalledVersion": "1:1.2.13.dfsg-1" which is vulnerable(see above msg). Is there a way to upgrade to zlib1g to 1.3.1 version in the python/ debain image?

raghu298 commented 7 months ago

@madler Is there a way to upgrade zlib1g to non-vulnerable version?

madler commented 7 months ago

You would have to find a version of the Python 3 executable with a newer zlib, or rebuild one yourself.

But you don't have to. Python does not use minizip, so there is no vulnerability. If you have installed the pyminizip package, it may be vulnerable, but your tool is not reporting it there. It is reporting the zlib version being used by the Python executable.

In short, you do not have a problem. trivy is wrong.

raghu298 commented 7 months ago

@madler i think python image is built on top of debain image so the tool is scanning python image and finding the vulenarability. Issue is with debian image

Ajith-Reddy1205 commented 7 months ago

Is there a way to upgrade zlib1g to non-vulnerable version? -- any update on this?

madler commented 7 months ago

@Ajith-Reddy1205 I don't know how to make this any clearer.

You do not have a problem that needs fixing. Your current version of zlib1g does not have that vulnerability. It does not have minizip in it. It never did. You do not need to do anything. Just carry on.
This is not the place to ask about how to update Python or Debian.

UBessle commented 7 months ago

Thanks for the clarification @madler, the remaining problem is, that trivvy marks it as vulnerable nevertheless and trivvy get's this information from the debian security tracker (https://security-tracker.debian.org/tracker/CVE-2023-45853), which claims, that zlib1g with version 1:1.2.13.dfsg-1 is indeed vulnerable. So the question is, how to get the entry in debian security tracker fixed? Because my management as well is asking me, when the critical vulnerability will be fixed.

VincentAntoine commented 6 months ago

Same here, debian images (and all images based on debian, including for instance python images) are marked as critically vulnerable by Trivy. As Trivy is based on debian security-tracker, and zlib 1.2 is marked as vulnerable in the debian security tracker, I guess it would require that the debian team upgrades zlib to 1.3 in a future release for Trivy to mark it as not vulnerable. But in the Trivy report, CVE-2023-45853 is marked as "Won't fix" in Debian Bookworm (which I wonder where this comes from ?) and zlib is upgraded to 1.3 only in Debian Trixie. So it looks like it will stay like this until the release of Trixie (next year ?).

~$ trivy image debian:stable-slim

debian:stable-slim (debian 12.5)

Total: 78 (UNKNOWN: 0, LOW: 57, MEDIUM: 15, HIGH: 5, CRITICAL: 1)

┌────────────────────┬─────────────────────┬──────────┬──────────────┬───────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│      Library       │    Vulnerability    │ Severity │    Status    │   Installed Version   │ Fixed Version │                            Title                             │
┌────────────────────┬─────────────────────┬──────────┬──────────────┬───────────────────────┬───────────────┬──────────────────────────────────────────────────────────────┐
│          ...       │         ...         │    ...   │     ...      │           ...         │      ...      │                            ...                               │
├────────────────────┼─────────────────────┼──────────┼──────────────┼───────────────────────┼───────────────┼──────────────────────────────────────────────────────────────┤
│ zlib1g             │ CVE-2023-45853      │ CRITICAL │ will_not_fix │ 1:1.2.13.dfsg-1       │               │ zlib: integer overflow and resultant heap-based buffer       │
│                    │                     │          │              │                       │               │ overflow in zipOpenNewFileInZip4_6                           │
│                    │                     │          │              │                       │               │ https://avd.aquasec.com/nvd/cve-2023-45853                   │
└────────────────────┴─────────────────────┴──────────┴──────────────┴───────────────────────┴───────────────┴──────────────────────────────────────────────────────────────┘

madler commented 6 months ago

Sigh. I tried.

It is this page: https://security-tracker.debian.org/tracker/CVE-2023-45853 , that incorrectly marks 1:1.2.13.dfsg-1 as vulnerable, when in fact it has no minizip code in it whatsoever. (I verified that by downloading it and listing the external symbols in the .so file.) I managed to reach someone at debian.org who seems to be in control of that page, but instead of fixing the page, they defended it, even though it's wrong.

VincentAntoine commented 6 months ago

This is really weird. It's really against their interest to have ALL Debian images flagged as critically vulnerable for so long.

superlazyname commented 5 months ago

I'm just putting this as a FYI, to try and help people who might land here looking for answers.

Mark's probably sick of hearing about this by now. Sorry Mark, I just didn't see anyone post a public discussion of this with the details I was looking for. Maybe at least I gave you some things to link to if it would help?

I did some legwork on this. From what I understand this is a false positive detection in the Debian images. Unfortunately there's a ton of Debian based container images that will get flagged, Debian is a very popular base image.
The source code of that particular version of zlib has a vulnerability, but the vulnerable part isn't in the Debian package. The Debian binary for zlib doesn't contain the vulnerable code.

Unfortunately it looks like Bookworm and all older releases will be flagged by this, and this will only be (coincidentally) fixed by the next major release (Trixie). Debian doesn't have a target date for that release right now, but if they keep up with their usual release schedule, I'd guess that won't be for over a year from now.

Here's some other things for further reading, I put more information in them:

Here's the discussion thread where I mentioned this was a false positive: https://github.com/aquasecurity/trivy/discussions/6722 . They said Debian misclassified the status of the CVE.
I also made a Debian bug report, https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1071276 and reached out to their security team. They said the CVE is classified properly.
It sounds like Debian is using "ignored" for this package instead of "not_affected" and that's what's giving trivy heartburn about this, and it sounds like they're not willing to change it from "ignored" to "not_affected".

I'm not sure if there's a way to modify the code of trivy to handle this case better, but it seems like there's not, because it sounds like "ignored" might be used in the Debian tracker for both "won't fix" and "not affected", and Trivy interprets "ignored" as "this container image is still vulnerable" so that distinction is very important for corporate vulnerability dashboards. I notice that Clair (https://github.com/quay/clair) also seems to have the same problem.

It would seem like the Debian tracker is meant for humans to read, not bots, and tools that try and "simplify" things by reducing that to "you have 10 vulnerabilities" have a hard time handling that. I'm not going to bug either trivy or Debian anymore.

Summary:

Don't bug Mark, there's nothing that can be done from his side
Whether debian or trivy is wrong depends on your definition of "ignored", "not affected", and "won't fix"
It seems like debian and trivy can't be made to agree on that.

Hope that helps

alexmaurizio commented 5 months ago

Note to Snyk users: you will find this reported as a critical, unfixable vulnerability on your dockers and you will sooner or later end up here.

@superlazyname answer applies to us too :)

stnert commented 2 weeks ago

In Arch Linux this needs removed of website (https://security.archlinux.org/) and arch-audit... Any chance of fixing this?

madler / zlib

minizip: Check length of comment, filename, and extra field, in zipOpenNewFileInZip4_64 #843