Vulnerability Development mailing list archives

Re: Antivirus scanner DoS with zip archives


From: teo () gecadsoftware com
Date: Tue, 19 Jun 2001 17:12:43 +0300

Hi Michel!
On Mon, 18 Jun 2001, Michel Arboi wrote:

Some time ago, MimeSweeper could be killed in a rather simple way:
Compress with zip a 1 GB file filled with zeros, and attach the 1MB (*)
result to an e-mail. MimeSweeper tried to allocate 1 GB of memory and
died.
(*) The maximum compressing ratio with the Zip algorithm is ~ 1:1000

This bug is supposed to be fixed in the last versions (I did not
check).

    ********

Instead of trying to eat all the memory, we could try to eat the CPU
like this:

Take some file _small_ file "A" and compress into A.zip
Copy (or rather link) 100 times A.zip to A1.zip .. A99.zip
Compress all those files into B.zip. 
B.zip will be much bigger than A.zip, but can be compressed (if A is
too big, the Zip algorithm cannot find similar substrings and fails to
compress B)
Copy (or link) B.zip to B1 .. B99.zip
Archive them to C.zip (not so big)
C.zip -> C1 .. C99 => D.zip

Now, D.zip contains 1000000 files, which is probably enough to keep any
antivirus scanner busy for a loooooong time.
I tried with winver.exe as my input file, the D.zip archive is about
600 KB -- not that big.

Out of curiosity I did that with our FreeBSD port of RAV (note that I am
not in the development team, and the opinions expressed here are mine only
and are not to be seen as commercial or something; or maybe only for FreeBSD :)

A.exe was a dd if=some_exe of=A.exe count=1000

[root@antares /root]# /usr/bin/time -l -o /tmp/time.stat  /usr/local/rav8/bin/ravav -UNZIP /home/teo/D.zip >/dev/null
[root@antares /root]# cat /tmp/time.stat
      288.80 real       263.98 user        16.34 sys
      6892  maximum resident set size
        36  average shared memory size
      5930  average unshared data size
       129  average unshared stack size
      2644  page reclaims
         0  page faults
         0  swaps
         0  block input operations
         0  block output operations
         0  messages sent
         0  messages received
         0  signals received
         0  voluntary context switches
     11659  involuntary context switches

[root@antares /root]# uname -a
FreeBSD xxx.gecadsoftware.com 4.2-RELEASE FreeBSD 4.2-RELEASE #6: Thu May  3 13:08:46 EEST 2001     
root () xxx gecadsoftware com:/usr/src/sys/compile/ANTARES  i386

The machine is a PIII/600 w/ 128M RAM.

During the test ravav showed in top eating somewhere arround 25% CPU and the system was 60% idle
with a machine also running qmail/mysql/postgres/apache and tons of ftp daemons :)

Oh, maybe also of interest:

[root@antares /root]# ulimit -a
core file size (blocks)     unlimited
data seg size (kbytes)      524288
file size (blocks)          unlimited
max locked memory (kbytes)  unlimited
max memory size (kbytes)    unlimited
open files                  2047
pipe size (512 bytes)       1
stack size (kbytes)         65536
cpu time (seconds)          unlimited
max user processes          1023
virtual memory (kbytes)     589824

I guess it should be good news (despite it took some time), cause else one can easily kill such a mail 
scanner 



    ********

A variant would be to use a viral code as the "A" file, triggering 1
million of alarms, filling the logs, the administration console, etc.
:)

this I didn't tried, as I don't have a virus handy. All are in safe places :)

A simple way to reject such things could be to set a timeout on the
scanning operation. If it takes too long, the file, attachment, web
page, whatever, is just rejected.

looks like a good candidate for login.conf/ulimit also


cheers

-- teodor


Current thread: