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
rootat_private:/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
This archive was generated by hypermail 2b30 : Wed Jun 20 2001 - 06:31:13 PDT