bugtraq - Re: Decompression Bombs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

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
>