[MacPorts] #60396: unzip @6.0_3 erroneously detects a possible zip bomb
MacPorts
noreply at macports.org
Sun Apr 26 13:27:51 UTC 2020
#60396: unzip @6.0_3 erroneously detects a possible zip bomb
-------------------------+----------------------
Reporter: udbraumann | Owner: gfiumara
Type: defect | Status: assigned
Priority: Normal | Milestone:
Component: ports | Version:
Resolution: | Keywords:
Port: unzip |
-------------------------+----------------------
Comment (by gfiumara):
[https://github.com/macports/macports-
ports/blob/master/archivers/unzip/files/23-cve-2019-13232-zip-bomb-with-
overlapped-entries.patch The] [https://github.com/macports/macports-
ports/blob/master/archivers/unzip/files/24-cve-2019-13232-do-not-raise-
alert-for-misplaced-central-directory.patch patches] for
[https://nvd.nist.gov/vuln/detail/CVE-2019-13232 CVE-2019-13232] (Zip
bombs) were applied in `unzip @6.0_3` two weeks ago. I suspect they are
the culprit. The file in question expands correctly with `unzip @6.0_3`
under macOS 10.15.4. I suspect it's related to
[https://github.com/madler/unzip/issues/2 this 32-bit issue], that is
fixed in the attached
[https://github.com/madler/unzip/commit/13f0260beae851f7d5dd96e9ef757d8d6d7daac1
patch].
Comments on the patch seem to indicate that this is a result of bad build
parameters. We are only enabling `LARGE_FILE_SUPPORT` on `x86_64`, which
was the primary change two weeks ago. I think we need to either add this
patch or enable `LARGE_FILE_SUPPORT` everywhere if it's supported
everywhere (`sizeof(off_t)` or `sizeof(long)` >= 8).
--
Ticket URL: <https://trac.macports.org/ticket/60396#comment:3>
MacPorts <https://www.macports.org/>
Ports system for macOS
More information about the macports-tickets
mailing list