-----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-----
