Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 5 Dec 2016 10:17:13 -0600
From: Tyler Hicks <>
Cc: "" <>,
 "Steven M. Schweda" <>
Subject: CVE Request: Info-Zip zipinfo buffer overflow

Alexis Vanden Eijnde has discovered a zipinfo buffer overflow and
reported it here:

It is very similar to, but different than, this `unzip -l` crasher:

The zipinfo buffer overflow occurs due to a flaw in zipinfo.c's
zi_short() function:

(gdb) bt
#0  0x00007ffff7833428 in __GI_raise (sig=sig@...ry=6) at
#1  0x00007ffff783502a in __GI_abort () at abort.c:89
#2  0x00007ffff78757ea in __libc_message (do_abort=do_abort@...ry=2,
fmt=fmt@...ry=0x7ffff798c8a2 "*** %s ***: %s terminated\n")
    at ../sysdeps/posix/libc_fatal.c:175
#3  0x00007ffff791656c in __GI___fortify_fail (msg=<optimized out>,
msg@...ry=0x7ffff798c833 "buffer overflow detected") at fortify_fail.c:37
#4  0x00007ffff7914570 in __GI___chk_fail () at chk_fail.c:28
#5  0x00007ffff7913ad9 in _IO_str_chk_overflow (fp=<optimized out>,
c=<optimized out>) at vsprintf_chk.c:31
#6  0x00007ffff78796b0 in __GI__IO_default_xsputn (f=0x7fffffffe040,
data=<optimized out>, n=4) at genops.c:455
#7  0x00007ffff784be00 in _IO_vfprintf_internal
(s=s@...ry=0x7fffffffe040, format=<optimized out>, format@...ry=0x420d93
    ap=ap@...ry=0x7fffffffe178) at vfprintf.c:1631
#8  0x00007ffff7913b64 in ___vsprintf_chk (s=0x7fffffffe301 "100",
flags=1, slen=4, format=0x420d93 "%03u", args=args@...ry=0x7fffffffe178)
    at vsprintf_chk.c:82
#9  0x00007ffff7913abd in ___sprintf_chk (s=s@...ry=0x7fffffffe301
"100", flags=flags@...ry=1, slen=slen@...ry=4,
format=format@...ry=0x420d93 "%03u")
    at sprintf_chk.c:31
#10 0x000000000041729b in sprintf (__fmt=0x420d93 "%03u",
__s=0x7fffffffe301 "100") at /usr/include/x86_64-linux-gnu/bits/stdio2.h:33
#11 zi_short () at zipinfo.c:1986
#12 zipinfo () at zipinfo.c:919
#13 0x000000000041144a in do_seekable (lastchance=lastchance@...ry=0) at
#14 0x0000000000411bdf in process_zipfiles () at process.c:401
#15 0x0000000000404191 in unzip (argc=0, argv=0x7fffffffe628) at
#16 0x00007ffff781e830 in __libc_start_main (main=0x401f60 <main>,
argc=2, argv=0x7fffffffe618, init=<optimized out>, fini=<optimized out>,
    rtld_fini=<optimized out>, stack_end=0x7fffffffe608) at
#17 0x0000000000401fa9 in _start ()

The overflow occurs when the two-byte compression method field in the
central directory file header is greater then 999. The sprintf at line
1986 overflows the methbuf buffer:

  1937  static int zi_short(__G)   /* return PK-type error code */
  1947      char        methbuf[5];
  1985      } else if (methnum >= NUM_METHODS) {   /* unknown */
  1986          sprintf(&methbuf[1], "%03u", G.crec.compression_method);
  1987      }

An offset of 1 byte + "999" + "\0" fills the entire buffer so a
compression method field of 1000 and greater overwrites bytes outside of
the buffer.

Please assign a CVE. Also, consider assigning a CVE to the related
`unzip -l` issue from 2014. Thank you!


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.