Re: [Full-Disclosure] [HV-MED] Zip/Linux long path buffer overflow

[Martin Pitt]

--vtzGhvizbBRQ85DL
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi!

vuln@hexview.com [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.
>=20
> Demonstration:
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> 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:
>=20
> 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 =3D strlen(f);
=20
+ if (len >=3D FNMAX)
+ error("file name too long");
+
if (f =3D=3D label) {
if (a !=3D NULL)
*a =3D label_mode;

Have a nice day,

Martin
--=20
Martin Pitt http://www.piware.de
Ubuntu Developer http://www.ubuntulinux.org
Debian GNU/Linux Developer http://www.debian.org

--vtzGhvizbBRQ85DL
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBi3+JDecnbV4Fd/IRAoQ5AJ9N4jy2zWbqtUwOolC7KHcPGamuUwCfRzWe
wLV2F/7W6fpbxnW34x0hbH0=
=ushy
-----END PGP SIGNATURE-----

--vtzGhvizbBRQ85DL--

[Josh Bressers]

On Fri, Nov 05, 2004 at 02:26:33PM +0100, Martin Pitt wrote:
> 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.

This fix will allow zip to create an archive with very long filenames.

I'm also changing the type of len from a signed int to size_t to prevent
trouble in the future.

--- zip-2.3/unix/unix.c.orig 2004-11-05 15:44:41.000000000 -0500
+++ zip-2.3/unix/unix.c 2004-11-05 15:50:28.000000000 -0500
@@ -319,8 +319,8 @@ iztimes *t; /* return value:
a file size of -1 */
{
struct stat s; /* results of stat() */
- char name[FNMAX];
- int len = strlen(f);
+ char *name;
+ size_t len = strlen(f);

if (f == label) {
if (a != NULL)
@@ -331,6 +331,11 @@ iztimes *t; /* return value:
t->atime = t->mtime = t->ctime = label_utim;
return label_time;
}
+
+ name = malloc(len+1);
+ if (!name)
+ return 0;
+
strcpy(name, f);
if (name[len - 1] == '/')
name[len - 1] = '\0';

--
JB