Re: Decompression Bombs

["Myron Davis" <myrond () xyxx com>]

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