Gzip & segmentation faults

=?UNKNOWN-8BIT?Q?Micha=B3?= Zalewski (lcamtuf@POLBOX.COM)
Thu, 25 Dec 1997 15:20:40 +0100

This is a multi-part message in MIME format.

Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: quoted-printable

Few days ago, I noticed a problem(s) with gzip and it's archives.
Gzip seems to be poorly-written with regard to range checking, so
it's quite easy to cause segmentation faults and buffer overflows.
Simpliest ooverflow can be done by passing to gzip/gunzip filename
longer than 1024 bytes:

$ gzip blahblahblahblah... [cut!]
Segmentation fault (core dumped).

Of course it shouldn't be really dangerous, but I also found
a few ways to cause segmentation faults (overflows? I'm not sure)
when 'lightly' altered archive is being uncompressed or even
_viewed_ with file managers like Midnight Commander.
If these SEGVs are exploitable overflows (fool's wish...) - even
viewing files may become dangerous. Of course there's also a chance
that it isn't exploitable, I have not enough time and experience to
check it. Maybe it's just another curious bug :)

Attached example of 'evil' archive (Altered.gz) has been created by
compressing empty file with gzip's -n switch. After all, byte at offset
0x0a (one of possibilities :) has been changed.
Under Linux, attempt of unziping or viewing this file will cause
nice segmentation fault. MS-DOS gzip screws-up totally.
I also noticed strange behaviour of VRML 2.0 plugins with M$IE (maybe
other browsers?) - they believes that every .gz file I wish to view
must be a compressed VRML file :).

OK, that's all, if anyone have enough time to check if it's possible
to exploit this bug... :)

Michal Zalewski [tel 9690] | finger 2 PGP [lcamtuf@boss.staszic.waw.pl]
=3D-------- [ echo "while [ -f \$0 ]; do \$0 &; done" >_;. _ ] =

Content-type: model/"vrmlx-world/x-vrml"; name=altered.gz
Content-disposition: attachment; filename=altered.gz
Content-transfer-encoding: base64