[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-Id: <16120515504112_2020046C@antinode.info>
Date: Mon, 5 Dec 2016 15:50:41 -0600 (CST)
From: "Steven M. Schweda" <sms@...inode.info>
To: tyhicks@...onical.com, oss-security@...ts.openwall.com
Cc: security@...ntu.com, Info-ZIP-Dev@...tley.com
Subject: CVE Request: Info-Zip zipinfo buffer overflow
From: Tyler Hicks <tyhicks@...onical.com>
Thanks for the (thorough, helpful) report.
> Alexis Vanden Eijnde has discovered a zipinfo buffer overflow and
> reported it here:
>
> https://launchpad.net/bugs/1643750
>
> It is very similar to, but different than, this `unzip -l` crasher:
>
> http://www.openwall.com/lists/oss-security/2014/11/03/5
It is. And the easy fix is also very similar (and should appear in
the next UnZip release, version 6.1e beta):
ALP $ gdiff zipinfo.c;39 zipinfo.c
2568c2568,2579
< sprintf(&methbuf[1], "%03u", G.crec.compression_method);
---
> /* 2016-12-05 SMS.
> * https://launchpad.net/bugs/1643750
> * Unexpectedly large compression methods overflow
> * &methbuf[]. Use the old, three-digit decimal format
> * for values which fit. Otherwise, sacrifice the "u",
> * and use four-digit hexadecimal.
> */
> if (G.crec.compression_method <= 999) {
> sprintf( &methbuf[ 1], "%03u", G.crec.compression_method);
> } else {
> sprintf( &methbuf[ 0], "%04X", G.crec.compression_method);
> }
Typical output (pre-release UnZip 6.1e beta, with some minor,
unrelated report format changes from UnZip 6.0):
Old:
ALP $ unzip6l -Z PoZ.zip
Archive: ALP$DKC0:[UTILITY.SOURCE.ZIP.test_mthd_ovflo]PoZ.zip;1
Zip file size: 154 bytes, number of entries: 1
-rw-rw-r-- 3.0 unx 2 tx u65535 16-Nov-21 19:07 a
^^^^^^
1 file, 2 bytes uncompressed, 2 bytes compressed: 0.0%
New/next:
ALP $ unzipx -Z PoZ.zip
Archive: ALP$DKC0:[UTILITY.SOURCE.ZIP.test_mthd_ovflo]PoZ.zip;1
Archive size: 154 bytes; Members: 1
-rw-rw-r-- 3.0 unx 2 tx FFFF 16-Nov-21 19:07 a
^^^^
Members: 1; Bytes uncompressed: 2, compressed: 2, 0.0%
Directories: 0, Files: 1, Links: 0
> The zipinfo buffer overflow occurs due to a flaw in zipinfo.c's
> zi_short() function:
> [...]
Yeah. We should have noticed this whan the "unzip -l" complaint was
made.
> Please assign a CVE. Also, consider assigning a CVE to the related
> `unzip -l` issue from 2014. Thank you!
Is that something I should do? (I normally get reports with CVEs; I
have never created one.)
------------------------------------------------------------------------
Steven M. Schweda sms@...inode-info
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
