[Mimedefang] survey: dropping password protected file

[Clayton, Nik [IT]]

We delete encrypted zip files if we can't decrypt them.  Zip encryption
isn't (typically) very strong, and in some cases we can decrypt the file and
scan it.

However, if we can't scan it, we don't let it through.  In part this is
because of regulatory requirements for handling of confidential data -- zip
encryption isn't strong enough, and this stops users, both inside and
outside Citigroup, from sending possibly sensitive data using a mechanism
that is not appropriate.

> A third option is to list the zip file directory and reject it if it
> contains either another zip file or any banned extensions.  Zip
> encryption encrypts the file contents, but it doesn't seem to encrypt
> the directory listing -- I tested an "unzip -l" on a captured
> encrypted virus, and it listed the .exe just fine.
> 
> We're going to look at integrating Archive::Zip into mimedefang, because
this
> is becoming an issue for our CanIt customers also.

Just started doing this here (well, I'll be testing it next week).  I might
be able to send you proof of concept code if I can get the necessary sign
off.  One of the things I've discovered from a simple test script is that
Archive::Zip on Solaris (or one of its dependencies) has memory leaks.

Take a look at http://people.freebsd.org/42/42.pl.  This should (safely)
process 42.zip, at the same location.  Don't try and extract 42.zip yourself
-- it recursively unextracts to 4.5 petabytes.  On FreeBSD, Linux, and a
bunch of other operating systems,

    perl 42.pl 42.zip

uses a steady 8 - 10MB of RAM.  On Solaris (at least, Solaris 2.8 plus
whatever patches we have here) it's RSS grows without bounds until it
eventually reaches the per-process memory allocation limit and gets killed.

N