Bug 70227 - app-arch/zip: buffer overflow
Bug#: 70227 Product:  Gentoo Security Version: unspecified Platform: All
OS/Version: All Status: RESOLVED Severity: major Priority: P2
Resolution: FIXED Assigned To: security@gentoo.org Reported By: koon@gentoo.org
Component: Vulnerabilities
URL: 
Summary: app-arch/zip: buffer overflow
Keywords:  
Status Whiteboard: A2 [glsa]
Opened: 2004-11-06 01:31 0000
Description:   Opened: 2004-11-06 01:31 0000
From Ubuntu :

HexView discovered a buffer overflow in the zip package. The overflow
is triggered by creating a ZIP archive of files with very long path
names. This vulnerability might result in execution of arbitrary code
with the privileges of the user who calls zip.

This flaw may lead to privilege escalation on systems which
automatically create ZIP archives of user supplied files, like backup
systems or web applications.


From HexView :

Overview:
=========
Zip console application by Info-Zip (http://www.info-zip.org) is an
open-source software and part of many Linux distributions.
A buffer overflow condition can be triggered and exploited during
recursive compression operation.

Affected products:
==================
HexView tested the issue using Zip 2.3 which comes as "zip" package
with Debian Linux. Possibly all earlier Info-Zip versions are vulnerable.
Info-Zip applications for other operating systems are also vulnerable,
but depending on operating system and file system restrictions, the
vulnerability may or may not be triggered or exploited.

Cause and Effect:
=================
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 ?? ()

------- Comment #1 From Thierry Carrez (RETIRED) 2004-11-06 01:34:33 0000 -------
Created an attachment (id=43387) [details]
zip-CAN-2004-1010.patch

Patch from Josh Bressers @ RedHat

------- Comment #2 From Thierry Carrez (RETIRED) 2004-11-06 01:38:10 0000 -------
No maintainer, security should patch.
Supplied patch applies cleanly...

------- Comment #3 From solar 2004-11-06 06:22:29 0000 -------
Overflow confirmed

for x in $(seq 0 9); do b=$x`perl -e 'print "A" x 254'` ; mkdir -p $b ; cd $b;  done
cd ../../../../../../../../../../

solar@simple z $ ulimit -c unlimited; zip -r file.zip *
zip: stack smashing attack in function filetime()
Aborted (core dumped)

------- Comment #4 From solar 2004-11-06 06:35:15 0000 -------
Patched in zip-2.3-r4

zip-2.3-r2:  ppc amd64 ppc64 arm sparc mips ia64 alpha hppa x86 
zip-2.3-r4:  ~amd64 ~hppa ~x86 ~mips ~ia64 ~ppc ~alpha ~sparc ~ppc64 ~arm

fixed confirmed working zip -r * no longer segfaults.

------- Comment #5 From solar 2004-11-06 06:36:49 0000 -------
Created an attachment (id=43406) [details]
file.zip

test file.zip

------- Comment #6 From Thierry Carrez (RETIRED) 2004-11-06 06:42:44 0000 -------
Arches, please test and mark stable. See ZIP file from comment #5.

------- Comment #7 From Markus Rothe 2004-11-06 07:04:21 0000 -------
Stable on ppc64

------- Comment #8 From Olivier Crete 2004-11-06 07:17:06 0000 -------
stable on x86

------- Comment #9 From Jason Wever (RETIRED) 2004-11-06 07:40:23 0000 -------
Stable on sparc.

------- Comment #10 From Karol Wojtaszek (RETIRED) 2004-11-06 08:04:11 0000 -------
Stable on amd64

------- Comment #11 From Tim Yamin (RETIRED) 2004-11-06 09:03:12 0000 -------
Reopening - please do not close security bugs until the GLSA has been issued.

------- Comment #12 From Tim Yamin (RETIRED) 2004-11-06 09:12:43 0000 -------
IA64 is done.

------- Comment #13 From Bryan Østergaard (RETIRED) 2004-11-06 13:12:59 0000 -------
Stable on alpha.

------- Comment #14 From Lars Weiler (RETIRED) 2004-11-06 13:41:58 0000 -------
Stable on ppc.

------- Comment #15 From Joshua Kinard 2004-11-07 01:49:57 0000 -------
mips stable.

------- Comment #16 From Sune Kloppenborg Jeppesen 2004-11-09 12:01:34 0000 -------
GLSA 200411-16