|
|
Message-ID: <1415009028.3552.40.camel@juliet.mcarpenter.org>
Date: Mon, 03 Nov 2014 11:03:48 +0100
From: Martin Carpenter <mcarpenter@...e.fr>
To: oss-security@...ts.openwall.com
Subject: unzip -l crasher
[For symmetry with Jakub's post; NB not the same flag]
There is a BO in "unzip -l" via list_files() in list.c:
342 sprintf(&methbuf[4], "%03u",
G.crec.compression_method);
("apt-get source unzip" on Ubuntu 14.04).
methbuf is an auto 8 char array:
118 min_info info;
119 char methbuf[8];
120 static ZCONST char dtype[]="NXFS"; /* see zi_short() */
*printf() field-width format specifiers don't restrict the length of the
output so you can probably affect other local variables with this.
min_info's first field is "offset" which sounds promising modulo
compiler choices/stack ordering/..., and max [probably] 6 bytes (length
of MAX_INT - 4) in just 0x30..0x39 available. I have a few reproducer
zips but I have not looked further at exploiting this. Fortify catches
this crash on both Red Hat and Ubuntu.
Although this is in the same area (compression) as the "unzip -t" thread
I don't think they are directly related: mancha's patch doesn't solve
this problem and "unzip -l unzip_t_malloc.zip" doesn't crash.
I'll drop a line to the InfoZip guys via their web interface so that
they see these two conversations.
Martin.
ps. found by "collateral damage" fuzzing dash(1) post shellshock :-7
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.