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

[zmodem]

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]

Applied.

[Neustradamus]

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

• 73331a6

[ljavorsk]

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

[ljavorsk]

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

[Persi]

@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]

@madler: Can you look?

[rossburton]

For anyone looking for the integrated patch, it's 73331a6.

[Neustradamus]

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

[rvoliveti-cpu]

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

[aiakubovich]

@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]

@madler could you please release a patch ?

[svadnala]

@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]

@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]

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

[raghu298]

@madler Can you help in fix the issue?

[madler]

@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]

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

[raghu298]

@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]

@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]

@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]

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

[madler]

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]

@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]

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

[madler]

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

1. 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.
2. This is not the place to ask about how to update Python or Debian.

[UBessle]

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]

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]

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]

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

[superlazyname]

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: Debian Bookworm CVE-2023-45853 in zlib 1:1.2.13.dfsg-1 has been marked as ignored, but trivy still shows it as a vulnerability aquasecurity/trivy#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]

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 :)