Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.