[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <1118.146.63.79.38.1076357162.squirrel@xyxx.com>
Date: Mon, 9 Feb 2004 11:06:02 -0900 (AKST)
From: "Myron Davis" <myrond@...x.com>
To: "Brian Dessent" <brian@...sent.net>
Cc: bugtraq@...urityfocus.com
Subject: Re: Decompression Bombs
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
>
Powered by blists - more mailing lists