I would "only" note that it looks like that packaging a file containing 2 Gigabyte of e.g. 0x31 chars into a ZIP archive also will have the same impact.
I only tested now Kaspersky AV 5.0.1.0:
$ zipinfo bzip2bomb-DANGEROUS-2GB-0x00.zip
Archive: bzip2bomb-DANGEROUS-2GB-0x00.zip 1941138 bytes 1 file
-rw-r--r-- 2.3 unx 2000000000 bx defN 12-Jan-04 14:50 bzip2bomb-DANGEROUS-2GB-0x00
1 file, 2000000000 bytes uncompressed, 1940950 bytes compressed: 99.9%
$ zipinfo bzip2bomb-DANGEROUS-2GB-0x31.zip
Archive: bzip2bomb-DANGEROUS-2GB-0x31.zip 1941139 bytes 1 file
-rw-r--r-- 2.3 unx 2000000000 tx defN 12-Jan-04 14:20 bzip2bomb-DANGEROUS-2GB-0x31
1 file, 2000000000 bytes uncompressed, 1940951 bytes compressed: 99.9%
Also the first one was not detected, resulting in usual (expected) eat-up of disk space and CPU power...
BTW: if a decompression unit checks the size ratio (compressed/uncompressed) by only evaluation of the ZIP header (like e.g. "arbomb" does), this is not enough.
Here, Linux "unzip" unpacks a ZIP file without warning to full size, even if the ZIP header ("adjusted" using an hexeditor) contain a too low value for uncompressed size of this file.
...next issue for AV vendor's QA?
Peter -- Dr. Peter Bieringer Phone: +49-8102-895190 AERAsec Network Services and Security GmbH Fax: +49-8102-895199 Wagenberger Stra�e 1 Mobile: +49-174-9015046 D-85662 Hohenbrunn E-Mail: [EMAIL PROTECTED] Germany Internet: http://www.aerasec.de
_______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
