--Boundary_(ID_pZVtqOegs5nIWe2NMiJ+aQ)
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
--Boundary_(ID_pZVtqOegs5nIWe2NMiJ+aQ)
Content-type: model/"vrmlx-world/x-vrml"; name=altered.gz
Content-disposition: attachment; filename=altered.gz
Content-transfer-encoding: base64
H4sIAAAAAAAAA5UAAAAAAAAAAAA=
--Boundary_(ID_pZVtqOegs5nIWe2NMiJ+aQ)--