All,
Thank you Santiago for the report and David for the diagnosis. Though this is
not a valid zip file, there are in fact no overlapping structures and so there
should not be a bomb alert.
I have added a commit that initializes the cover with the actual spans of the
central directory, the Zip64 end of central directory record if present, and
the end of central directory record (the latter of which may include the Zip64
end of central directory locator). unzip then processes the funky omni.ja file
without a bomb alert.
See:
https://github.com/madler/unzip/commit/6d351831be705cc26d897db44f878a978f4138fc
Mark
> On Jul 19, 2019, at 9:53 AM, David Fifield <da...@bamsoftware.com> wrote:
>
> On Fri, Jul 19, 2019 at 08:30:32AM +0900, Mike Hommey wrote:
>> Download
>> http://ftp.mozilla.org/pub/firefox/releases/68.0.1/linux-x86_64/en-US/firefox-68.0.1.tar.bz2
>> Extract it
>> Unzip omni.ja
>>
>> The file *is* funky, but afaik it does not have overlapping components.
>
> I think I know what's going on here--the Firefox omni.ja file uses an
> unusual zip layout, specific to Firefox, that puts the central directory
> at the *beginning* of the file, rather than the end. This is meant to
> allow for better disk caching when unpacking omni.ja, or something.
> https://bugzilla.mozilla.org/show_bug.cgi?id=559961
> https://bugzilla.mozilla.org/show_bug.cgi?id=589368
>
> You can see in this code sample, first Firefox looks for the central
> directory at offset 4, then falls back to the usual EOCD search.
> https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l597
> https://hg.mozilla.org/mozilla-central/file/af29567ecdba/modules/libjar/nsZipArchive.cpp#l638
>
> You can see this in the output of "zipinfo" as well; the central
> directory is at offset 4, and it shows warning relating to the unusual
> layout. (I'm using zipinfo 6.0-21+deb9u1 from Buster, which hasn't been
> patched yet.)
> $ zipinfo -v /usr/lib/firefox-esr/omni.ja
> The central directory is 111932 (000000000001B53Ch) bytes long,
> and its (expected) offset in bytes from the beginning of the zipfile
> is 4 (0000000000000004h).
>
> warning [/usr/lib/firefox-esr/omni.ja]: 16789751 extra bytes at
> beginning or within zipfile
> (attempting to process anyway)
> error [/usr/lib/firefox-esr/omni.ja]: reported length of central
> directory is
> -16789751 bytes too long (Atari STZip zipfile? J.H.Holm ZIPSPLIT 1.1
> zipfile?). Compensating...
>
> The unzip patch starts by initializing a cover that extends from the
> beginning of the central directory to the end of the file. In the case
> of the Firefox layout, that's the *entire* file, except for the first 4
> bytes. So while none of the file overlap each other, they all appear to
> overlap the central directory.
> https://github.com/madler/unzip/commit/47b3ceae397d21bf822bc2ac73052a4b1daf8e1c#diff-42593f5e58d2da2cb6b6a937a04e16ddR496
>
> The Firefox layout has also caused problems with 7-Zip:
> https://sourceforge.net/tracker/?func=detail&aid=3065694&group_id=14481&atid=114481
>
> One possible solution is to adjust the bomb-cover patch so it only
> covers the actual length of the central directory (and the EOCD)
> separately. In almost all normal zip files, these two structures will be
> adjacent, so the effect will be the same as now.
