Hi!
vuln@xxxxxxxxxxx [2004-11-03 15:11 -0800]:
> When zip performs recursive folder compression, it does not check
> for the length of resulting path. If the path is too long, a buffer
> overflow occurs leading to stack corruption and segmentation fault.
> It is possible to exploit this vulnerability by embedding a shellcode
> in directory or file name. While the issue is not of primary concern
> for regular users, it can be critical for environments where zip archives
> are re-compressed automatically using Info-Zip application.
>
> Demonstration:
> ==============
> The issue can be reproduced by following these steps:
> 1. Create an 8-level directory structure, where each directory name is
> 256 characters long (we used 256 'a' characters).
> 2. run "zip -r file.zip *". The application will crash with
> "segmentation fault"
> 3. run "gdb -core core `which zip`" (assuming core drop is enabled)
> 4. type "where" and hit Enter. Here is what you'll see:
>
> Program terminated with signal 11, Segmentation fault.
> [garbage truncated]
> #0 0x0805108e in error ()
> #1 0x61616161 in ?? ()
> #2 0x61616161 in ?? ()
> #3 0x61616161 in ?? ()
I prepared a small fix for this (see below). It does not make zip work
with long file names, but at least it exits cleanly with giving the
reason, and does not segfault.
diff -Nur zip-2.30/unix/unix.c zip-2.30.new/unix/unix.c
--- zip-2.30/unix/unix.c 2004-11-05 14:22:42.957410560 +0100
+++ zip-2.30.new/unix/unix.c 2004-11-05 14:22:03.620390696 +0100
@@ -322,6 +322,9 @@
char name[FNMAX];
int len = strlen(f);
+ if (len >= FNMAX)
+ error("file name too long");
+
if (f == label) {
if (a != NULL)
*a = label_mode;
Have a nice day,
Martin
--
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org
Attachment:
signature.asc
Description: Digital signature