Re: unzip -t crasher

[mancha <mancha1 () zoho com>]

On Mon, Nov 03, 2014 at 07:42:06AM +0000, mancha wrote:
> On Sun, Nov 02, 2014 at 07:06:40PM +0100, Jakub Wilk wrote:
> > Latest American fuzzy lop[0] tarball[1] contains a zip file that
> > crashes unzip -t:
> >
> > $ unzip -qt afl-0.43b/docs/samples/unzip_t_malloc.zip foo/:
> > mismatching "local" filename (™/UT), continuing with "central"
> > filename version *** Error in `unzip': free(): corrupted unsorted
> > chunks: 0x00000000015d0170 ***
> >
> > I'm not sure if inclusion of said zip file was intentional, but since
> > the cat is already out of the bag, I thought I'll let you know.
>
> Cats shouldn't be in bags, anyways.
>
> The crasher has an OS/2 extra field that claims to have a compressed
> block size of 52735 bytes and an uncompressed block size of 127 bytes.
>
> The attached patch against UnZip 6.0 ensures, within extra fields, 
> size(compressed) <= size(uncompressed) and should fix this issue.
>
> --mancha
>
> PS If the attachment gets mangled, it's also at:
> http://sf.net/projects/mancha/files/sec/unzip-6.0_overflow.diff

This buggy code path is traversed when a ZIP archive has <<extra
fields>> with blocks that are uncompressed (i.e. using the STORED
method). A better solution than my last patch or malloc'ing max(),
is returning an invalid compressed data error when size(compressed)!=
size(uncompressed) for these cases. The attached patch does just that.
Comments welcome.

Cheers.

--mancha

PS I have been CC'ing Christian Spieler via the only email I could find
online. I've not gotten bounces so it might still be active.

Attachment: unzip-6.0_overflow2.diff
Description:

Attachment: _bin
Description: