only allow 3-4 layers of zip's, each time you uncompress the zip file, run the check on it. The whole purpose is too not uncompress the zip bomb and not cause a large resource drain on the system by tricking the scanner to waste unneeded cycles on thrashing against a uncompressible zip. I haven't done this, but I'd imagine if one ran a count for each zip file uncompressed , such as (following is just psueodo code) -- TOTAL_SIZE = `$TOTAL_SIZE + unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4 -d' '` IF ($TOTAL_SIZE > $MAX_ALLOWED_SIZE) exit; -- just keep a running account of the size, should stop these kinds of zip bombs cold. I imagine one could also add more fuzzy logic such as, x many layers deep of zip files adding to the more likely hood of a message/file being dropped as tainted. -Myron > Myron Davis wrote: > >> This as far as I know is fairly well known as we had a problem with this >> a >> while back (by accident). >> >> We put a little check in like this: >> >> unzip -l $SANITIZED_ZIP_FILE|tail -n 1|cut -f4 -d' ' >> >> then checked the size .. if it was larger then oohh.. 400 megs, then >> drop >> it w/ an error for it being too large. > > This check will fail for all but the most naive of bombs. For example, > consider the file located at <http://www.unforgettable.dk/42.zip>. This > file contains a number of recursively nested ZIP files, to a depth of > 5. Compressed it is only 41kB, yet unpacks to 4.5 PB > (4,503,599,626,321,920 bytes) in total. > > $ unzip -l 42.zip > Archive: 42.zip > Length Date Time Name > -------- ---- ---- ---- > 34902 03-28-00 21:40 lib 3.zip > 34902 03-28-00 21:40 lib 1.zip > 34902 03-28-00 21:40 lib 2.zip > 34902 03-28-00 21:40 lib 0.zip > 34902 03-28-00 21:40 lib 4.zip > 34902 03-28-00 21:40 lib 5.zip > 34902 03-28-00 21:40 lib 6.zip > 34902 03-28-00 21:40 lib 7.zip > 34902 03-28-00 21:40 lib 8.zip > 34902 03-28-00 21:40 lib 9.zip > 34902 03-28-00 21:40 lib a.zip > 34902 03-28-00 21:40 lib b.zip > 34902 03-28-00 21:40 lib c.zip > 34902 03-28-00 21:40 lib d.zip > 34902 03-28-00 21:40 lib e.zip > 34902 03-28-00 21:40 lib f.zip > -------- ------- > 558432 16 files > > Your virus scanner will probably try to descend each of those archives, > and will croak if it does not recognise this as malware. > > Brian >
