Bugtraq mailing list archives

Re: Anti Virus Mailscanners DOS


From: arivanov () sigsegv cx
Date: Tue, 26 Feb 2002 14:49:17 -0000 (GMT)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi list,

        I would like to follow up in a bit more detail on Eduardo's post.

        Many AV software suites suffer from wrong decompression
implementations. It is not just checking of sizes. It is also failing to control
resources while decompressing and failing to maintain keepalive where
applicable while decompressing. This gives a possibility to create various nice
D.O.Ses.

Background:

        Most AV vendors currently support various mail scanning and firewall
plugin models for their products. In this mode their software spools a smtp
message or downloads a copy of file via http, decompresses it and scans it. 
        It is obvious that this process may take some time, so most AV products
start to "trickle" data to the customer after some predefined amount has been
downloaded. Otherwise the connection times out.

Bug:

Recently as a result of unplesant experience with Trend Viruswall I have found
out that :

        1. Apparenly its decompression strategy is download, than decompress.
It does not decompress on the fly while downloading formats that will allow this
like gz, bz2, tar.gz, tar, etc. 
        As a result if the file is a big archive the system may slow down to a
grinding halt while scanning the file "at once" after it has been downloaded.
During that period there is simply no CPU left for the AV checker to process
requests. 
        DOS. 
        Silly one. 
        Easily avoidable if "stream" formats are treated as such and
decompressed and scanned on the fly. IMHO, the bug posted in the
original post falls into this general category. 

        2. Lack of throttle down capability. A scanning process that has ran
for a while is both: likely to continue running (big file) and likely to eat up
CPU so that other requests will not be serviced. 
        This is also easily avoidable if threads that have run more than X
second start to yield some of their scheduled CPU time.

Example with a real URL and a real world scenario:

        Try to download the FreeBSD ports collection across a Viruswall
install:
        

        1. It is guaranteed to fail due to the fact that Viruswall forgets to
"trickle" while scanning. Scanning this nice little 16MB archive (100MB
decompressed) takes several minutes.

        2. Even one thread trying to download this file DOSes the Viruswall
completely. All other web traffic across the Viruswall starts to timeout.

        Unintentionally tested on a Checkpoint FW1 + Viruswall combination.
Sorry do not know the exact versions (but should be fairly fresh).

        Most likely Trend is not the only AV system suffering from both
defficiencies.

On 25-Feb-2002 Eduardo R. Maciel wrote:
-----------------------------------
-----[ SECURITY ANNOUNCEMENT ]-----
-----------------------------------
iNetd Security Research Annoucement

Name: Anti Virus Mailscanners DOS 
Systems Affected: System independant
Date: 25/02/2002
Subject: Potential DOS.
Severity: HIGH
Author: Eduardo R. Maciel (maciel () inetd com br)


Description
===========
An antivirus mailscanner should check the filesizes inside a compressed file
like .tar.gz, .zip, .bz2, etc, BEFORE open the file for scanning.

All the products that doesn't do that checking are vulnerable to a Denial Of
Service attack.

Pay attention to the procedure below:

root@maciel:/tmp# dd if=/dev/zero of=/tmp/file count=200000

root@maciel:/tmp# ls -l /tmp/file
-rw-r--r--    1 root  root    102400000 Feb 24 22:13 file

root@maciel:/tmp# bzip2 -z file

root@maciel:/tmp# ls -l /tmp/file.bz2
rw-r--r--     1 root  root    113 Feb 24 22:14 file

Since the file has only null (numerical zeros, not the ASCII kind)
characters, the size of the compressed file was reduced to a almost
insignificant value.
Sending several mails with these compressed files may let a machine out of
memory or disk space. 

Solution
========
      The mailscanner should check the filesizes inside a compressed file.



Credits:
      Eduardo R. Maciel
      maciel () inetd com br

- ----------------------------------
Anton R. Ivanov
ARI2-RIPE
Today's deliverables will have to be delayed because:

system consumed all the paper for paging

- ----------------------------------
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE8e6Bs4QelTkllq+4RAusSAKCd7bRIEXMGaiLjQ5hc+CUXMoV3GQCfRHPA
+sfoJGohhDDLxaFX6v9vE58=
=43fO
-----END PGP SIGNATURE-----


Current thread: