Gzip & segmentation faults

[lcamtuf () POLBOX COM (Micha? Zalewski)]

This is a multi-part message in MIME format.

------=_NextPart_000_005C_01BD1148.A9354500
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" >_;. _ ] =
---------=3D



------=_NextPart_000_005C_01BD1148.A9354500
Content-Type: model/vrml,x-world/x-vrml;
        name="altered.gz"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
        filename="altered.gz"

H4sIAAAAAAAAA5UAAAAAAAAAAAA=

------=_NextPart_000_005C_01BD1148.A9354500--