Bug 2227130

A zip file that meets the following criteria incorrectly triggers the zipbomb detection used to mitigate CVE-2019-13232:
1.  Is larger than 4GB
2.  Uses data descriptors (these are commonly created by the zip implementations in Java and Golang)
3.  Has a file located more than 4GB into the zip file that is shorter than 4GB
4.  Has another file after the previous file.

Fedora's patches for unzip have https://github.com/madler/unzip/commit/122050bac16fae82a460ff739fb1ca0f106e9d85, which contains a bug.  It assumes that a file that uses zip64 extensions in the central directory also uses zip64 extensions in the data descriptor if present.  The zip64 extensions are necessary in the central directory for files whose offset in the zip file is more than 4 GB, even if the file's compressed and uncompressed files fit in the non-zip64 fields.  There is no offset field in the data descriptor, so the zip64 data descriptor is only needed for files whose compressed or uncompressed sizes are more than 4 GB.

Reproducible: Always

Steps to Reproduce:
Create a jar file that meets the above criteria.  Jar is used instead of zip to create the file because Java's zip implementation is streaming so it has to use data descriptors to store the compressed and uncompressed sizes:

# Create an empty 4 GB file
truncate -s 4G 4g.bin
# Add it uncompressed to a jar file to make the size of the jar more than 4 GB:
jar -0 -c -f test.jar 4g.bin
# Add two smaller files
jar -u -f test.jar /etc/redhat-release /etc/fedora-release
# Read the jar file with unzip:
unzip -t test.jar etc/*

Actual Results:  
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


Expected Results:  
No error should be printed, there is no overlap in the file.

This is fixed in the zipbomb fork of unzip by https://github.com/madler/unzip/commit/3bee0689f7dc6afb88bda09ffb71b6b15623ff92, which significantly modifies the way data descriptors are parsed.  I'll also attach an alternative smaller, more targeted patch that fixes the issue by correctly detecting when a zip64 data descriptor is in use.

This bug affects some real world use cases.  Android's platform build system uses Go to create zip files, and when they are larger than 4 GB they can trigger this bug.  This can prevent building Android on Fedora.  https://bbs.archlinux.org/viewtopic.php?id=277610 is a similar report on Arch linux, which is using Fedora's patches.