Re: CVE Request: Info-ZIP unzip 6.0

["Steven M. Schweda" <sms () antinode info>]

From: Tomas Hoger <thoger () redhat com>

> Your patch, unzip-6.0_overflow2.diff, which is what got applied
> upstream, seems to perform an incorrect check.  It ensures that
> eb_ucsize is equal to eb_size - compr_offset.  The latter value
> includes compression header length (EB_CMPRHEADLEN), which is not
> included in eb_ucsize AFAICT (based on what I could find in
> extrafld.txt or os2/os2zip.c in Zip 3.0 sources).  It seems the check
> should be:
>
>   (eb_size - compr_offset - EB_CMPRHEADLEN != eb_ucsize)
>
> Can you or upstream confirm?
>
> This problem would not be a security problem, but a bug that could
> cause well-formed extra fields to be rejected as invalid.

   Hello.  I'm upstream.

   Thanks for the report.  I may be easily swayed, but I agree.  I was
more worried about the buffer-overflow problems, and did not carefully
analyze this part of the patch.  As I read the spec (for OS/2), eb_size
should include the 4-byte eb_ucsize value (eb_cmpr_offs = EB_OS2_HLEN ->
compr_offset), the 6-byte compressed-data header (2-byte compression
method plus 4-byte CRC = EB_CMPRHEADLEN), and the eb_ucsize bytes of
compressed (well, STOREd, actually) data.

   Part of the fun here is that I have no easy access to an actual OS/2
(or AtheOS, or BeOS, or pre-OS-X Mac, or ...) system, which makes it
tough to run a real test on this code.  (The rest of the world is
probably in the same boat, so it's not clear that anyone would ever
notice this, but it can't hurt (much) to make it correct.)

   Unless someone talks me out of it soon, I'll make some equivalent
change to the replacement 6.00 extract.c (and the current development
edition), and throw it into the pile here.

------------------------------------------------------------------------

   Steven M. Schweda               sms@antinode-info
   382 South Warwick Street        (+1) 651-699-9818
   Saint Paul  MN  55105-2547