Onderwerp: Decompression Bombs

As a followup to http://www.securityfocus.com/bid/9393/, where we
pointed out vulnerabilities of some antivirus-gateways while
decompressing bzip2-bombs, we were interested in the behaviour of
various applications that process compressed data.

It looks as if not only bzip2 bombs, but also decompression bombs in
general might cause problems. Compression is used in many applications,
but hardly any maximum size limits are checked during the decompression
of untrusted content.

We've created several bombs (bzip2, gzip, zip, mime-embedded bombs, png
and gif graphics, openoffice zip bombs). With these we tested some more
applications like additional antivirus engines, various web browsers,
openoffice.org, and the Gimp.

As a result, much more applications as we thought crashed. The
manufacturers of software should care more about the processing of
untrusted input.

For details see our full advisory, written by Dr. Peter Bieringer:
http://www.aerasec.de/security/advis...erability.html

Best regards,
Dr. Matthias Leu
--
AERAsec Network Services and Security GmbH
Wagenberger Strasse 1
D-85662 Hohenbrunn, Germany
http://www.aerasec.de

This as far as I know is fairly well known as we had a problem with this a
while back (by accident).

We put a little check in like this:

unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4 -d' '

then checked the size .. if it was larger then oohh.. 400 megs, then drop
it w/ an error for it being too large.

easy way to generate a large zip file is to do something like this:

dd if=/dev/zero of=testfile count=10000&&gzip testfile&&ls -la testfile

should get huge file to test w/ mighty quickly, try sending that to a few
virus scanners.

Theoretically one could modify a worm to send random zip'd files of zeros
along the way to different hosts to really kill the destinations
computers.

-Myron


> Wow, This is a very interesting concept. Any vendor that relies on any
> decompresion library could be vulnerable. Anything from something like
> Photoshop to IE to virus scanners.
>
> The example files given on the website seem to require a password. Can
> you provide it?
>
> Nice work and thanks!
>
> Dave Bachtel
> IT Intern
> RealTime Gaming
> Atlanta, GA - USA
> 404-459-4263 x139
> ♥♣♦â™
>
>
> -----Original Message-----
> From: Matthias Leu [mailto:mleu@aerasec.de]
> Sent: Tuesday, February 03, 2004 12:04 PM
> To: bugtraq@securityfocus.com
> Subject: Decompression Bombs
>
>
> As a followup to http://www.securityfocus.com/bid/9393/, where we
> pointed out vulnerabilities of some antivirus-gateways while
> decompressing bzip2-bombs, we were interested in the behaviour of
> various applications that process compressed data.
>
> It looks as if not only bzip2 bombs, but also decompression bombs in
> general might cause problems. Compression is used in many applications,
> but hardly any maximum size limits are checked during the decompression
> of untrusted content.
>
> We've created several bombs (bzip2, gzip, zip, mime-embedded bombs, png
> and gif graphics, openoffice zip bombs). With these we tested some more
> applications like additional antivirus engines, various web browsers,
> openoffice.org, and the Gimp.
>
> As a result, much more applications as we thought crashed. The
> manufacturers of software should care more about the processing of
> untrusted input.
>
> For details see our full advisory, written by Dr. Peter Bieringer:
> http://www.aerasec.de/security/advis...erability.html
>
> Best regards,
> Dr. Matthias Leu
> --
> AERAsec Network Services and Security GmbH
> Wagenberger Strasse 1
> D-85662 Hohenbrunn, Germany
> http://www.aerasec.de
>
>
>

Myron Davis wrote:

> This as far as I know is fairly well known as we had a problem with this a
> while back (by accident).
>
> We put a little check in like this:
>
> unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4 -d' '
>
> then checked the size .. if it was larger then oohh.. 400 megs, then drop
> it w/ an error for it being too large.

This check will fail for all but the most naive of bombs. For example,
consider the file located at <http://www.unforgettable.dk/42.zip>. This
file contains a number of recursively nested ZIP files, to a depth of
5. Compressed it is only 41kB, yet unpacks to 4.5 PB
(4,503,599,626,321,920 bytes) in total.

$ unzip -l 42.zip
Archive: 42.zip
Length Date Time Name
-------- ---- ---- ----
34902 03-28-00 21:40 lib 3.zip
34902 03-28-00 21:40 lib 1.zip
34902 03-28-00 21:40 lib 2.zip
34902 03-28-00 21:40 lib 0.zip
34902 03-28-00 21:40 lib 4.zip
34902 03-28-00 21:40 lib 5.zip
34902 03-28-00 21:40 lib 6.zip
34902 03-28-00 21:40 lib 7.zip
34902 03-28-00 21:40 lib 8.zip
34902 03-28-00 21:40 lib 9.zip
34902 03-28-00 21:40 lib a.zip
34902 03-28-00 21:40 lib b.zip
34902 03-28-00 21:40 lib c.zip
34902 03-28-00 21:40 lib d.zip
34902 03-28-00 21:40 lib e.zip
34902 03-28-00 21:40 lib f.zip
-------- -------
558432 16 files

Your virus scanner will probably try to descend each of those archives,
and will croak if it does not recognise this as malware.

Brian

> dd if=/dev/zero of=testfile count=10000&&gzip testfile&&ls -la testfile
No need to fill up your own disk -- do this instead:
dd if=/dev/zero bs=1k count=10000 | gzip - > testfile.gz

"Myron Davis" <myrond@xyxx.com> writes:

> Theoretically one could modify a worm to send random zip'd files of zeros
> along the way to different hosts to really kill the destinations
> computers.
>

Is this all just back to fail open/fail closed? I have a file that
will cause XXX virus scanner to crash. Does the SMTP agent view that
as a reason to reject the email or does it pass it through?

If it does a temporary rejection message because of some internal
failure, the infection rateof these messages becomes very low. Not
sure how virus scanners + SMTP servers interact with regards to
tradition SMTP errors.

It would be an effective anti-cleanup method though.
--
Chris Green <cmg@dok.org>
Fame may be fleeting but obscurity is forever.

In-Reply-To: <7DB0958915FDD611961400A0C98F18464E8DB1@WINTRIX.th ermeon.com>

I feel.. softwares should check the actual intrigity of data first... before extracting the archive insted completely trusting on the header information.

[this will indeed show down the decompression process to some extent...]

But, if the decompressor engines are used by Anti-virus softwarem... etc it should break the operation and insted list it in its error logs.

but say, a file is stored in a disk and the disk cluster that hold the header info. of the archive gets corrupt! in that case..... the only way to recover the data would be to check the intrigity of the archive and recover!

---the only solution could be, ... using small digital signatures in the archive [say, something like public key of PGP] and only trusted archive should be opened trusting it's header... otherwise, the decompressor engines should check the real intrigity
of data as well, before proceding further. ----

.... I do wanna know what are your views cauz, If you try to write a code to secure from such problems, it will certainly slow down a normal operation...

[..I feel, soon the world will see digital certificates in JPG files (O; ]

---------------------------------------------------------------------



>> dd if=/dev/zero of=testfile count=10000&&gzip testfile&&ls -la testfile
>No need to fill up your own disk -- do this instead:
>dd if=/dev/zero bs=1k count=10000 | gzip - > testfile.gz
>

only allow 3-4 layers of zip's, each time you uncompress the zip file, run
the check on it.

The whole purpose is too not uncompress the zip bomb and not cause a large
resource drain on the system by tricking the scanner to waste unneeded
cycles on thrashing against a uncompressible zip.

I haven't done this, but I'd imagine if one ran a count for each zip file
uncompressed , such as
(following is just psueodo code)

--
TOTAL_SIZE = `$TOTAL_SIZE + unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4
-d' '`

IF ($TOTAL_SIZE > $MAX_ALLOWED_SIZE)
exit;
--

just keep a running account of the size, should stop these kinds of zip
bombs cold.

I imagine one could also add more fuzzy logic such as, x many layers deep
of zip files adding to the more likely hood of a message/file being
dropped as tainted.

-Myron

> Myron Davis wrote:
>
>> This as far as I know is fairly well known as we had a problem with this
>> a
>> while back (by accident).
>>
>> We put a little check in like this:
>>
>> unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4 -d' '
>>
>> then checked the size .. if it was larger then oohh.. 400 megs, then
>> drop
>> it w/ an error for it being too large.
>
> This check will fail for all but the most naive of bombs. For example,
> consider the file located at <http://www.unforgettable.dk/42.zip>. This
> file contains a number of recursively nested ZIP files, to a depth of
> 5. Compressed it is only 41kB, yet unpacks to 4.5 PB
> (4,503,599,626,321,920 bytes) in total.
>
> $ unzip -l 42.zip
> Archive: 42.zip
> Length Date Time Name
> -------- ---- ---- ----
> 34902 03-28-00 21:40 lib 3.zip
> 34902 03-28-00 21:40 lib 1.zip
> 34902 03-28-00 21:40 lib 2.zip
> 34902 03-28-00 21:40 lib 0.zip
> 34902 03-28-00 21:40 lib 4.zip
> 34902 03-28-00 21:40 lib 5.zip
> 34902 03-28-00 21:40 lib 6.zip
> 34902 03-28-00 21:40 lib 7.zip
> 34902 03-28-00 21:40 lib 8.zip
> 34902 03-28-00 21:40 lib 9.zip
> 34902 03-28-00 21:40 lib a.zip
> 34902 03-28-00 21:40 lib b.zip
> 34902 03-28-00 21:40 lib c.zip
> 34902 03-28-00 21:40 lib d.zip
> 34902 03-28-00 21:40 lib e.zip
> 34902 03-28-00 21:40 lib f.zip
> -------- -------
> 558432 16 files
>
> Your virus scanner will probably try to descend each of those archives,
> and will croak if it does not recognise this as malware.
>
> Brian
>