|Summary:||app-arch/zip: buffer overflow|
|Product:||Gentoo Security||Reporter:||Thierry Carrez (RETIRED) <koon>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Package list:||Runtime testing required:||---|
Description Thierry Carrez (RETIRED) 2004-11-06 01:31:17 UTC
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 Thierry Carrez (RETIRED) 2004-11-06 01:34:33 UTC
Created attachment 43387 [details, diff] zip-CAN-2004-1010.patch Patch from Josh Bressers @ RedHat
Comment 2 Thierry Carrez (RETIRED) 2004-11-06 01:38:10 UTC
No maintainer, security should patch. Supplied patch applies cleanly...
Comment 3 solar (RETIRED) 2004-11-06 06:22:29 UTC
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 solar (RETIRED) 2004-11-06 06:35:15 UTC
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 solar (RETIRED) 2004-11-06 06:36:49 UTC
Created attachment 43406 [details] file.zip test file.zip
Comment 6 Thierry Carrez (RETIRED) 2004-11-06 06:42:44 UTC
Arches, please test and mark stable. See ZIP file from comment #5.
Comment 7 Markus Rothe (RETIRED) 2004-11-06 07:04:21 UTC
Stable on ppc64
Comment 8 Olivier Crete (RETIRED) 2004-11-06 07:17:06 UTC
stable on x86
Comment 9 Jason Wever (RETIRED) 2004-11-06 07:40:23 UTC
Stable on sparc.
Comment 10 Karol Wojtaszek (RETIRED) 2004-11-06 08:04:11 UTC
Stable on amd64
Comment 11 Tim Yamin (RETIRED) 2004-11-06 09:03:12 UTC
Reopening - please do not close security bugs until the GLSA has been issued.
Comment 12 Tim Yamin (RETIRED) 2004-11-06 09:12:43 UTC
IA64 is done.
Comment 13 Bryan Østergaard (RETIRED) 2004-11-06 13:12:59 UTC
Stable on alpha.
Comment 14 Lars Weiler (RETIRED) 2004-11-06 13:41:58 UTC
Stable on ppc.
Comment 15 Joshua Kinard 2004-11-07 01:49:57 UTC
Comment 16 Sune Kloppenborg Jeppesen 2004-11-09 12:01:34 UTC