[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