[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <93993db8-1bd4-85e5-fe22-06d3a4e44117@canonical.com>
Date: Mon, 5 Dec 2016 10:17:13 -0600
From: Tyler Hicks <tyhicks@...onical.com>
To: oss-security@...ts.openwall.com
Cc: "security@...ntu.com" <security@...ntu.com>,
"Steven M. Schweda" <sms@...inode.info>
Subject: CVE Request: Info-Zip zipinfo buffer overflow
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
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
../sysdeps/unix/sysv/linux/raise.c:54
#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
"%03u",
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
process.c:974
#14 0x0000000000411bdf in process_zipfiles () at process.c:401
#15 0x0000000000404191 in unzip (argc=0, argv=0x7fffffffe628) at
unzip.c:1278
#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
../csu/libc-start.c:291
#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!
Tyler
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.
