Professional Software Engineering wrote:
[...] As per a previous exchange on this topic here on this list, it
should be noted that this set of recipes doesn't actually identify
the file as a virus (or any other form of malware), but rather
quarantines zips which contain executable files.
Actually, it's "quarantines _files named with the .zip extention_" and
"which contain _specific types_ of executable files", no? After all,
WinZip will gladly handle "[...] TAR, Z, GZ, TGZ, CAB, UUencode, BinHex,
and MIME." Again, any anti-virus scanner should work _regardless of file
name_.
I'm losing track of what I read where, but I think it was one of the
anti-virus lists where the trick of using 'file' to confirm a file's
purported content was suggested. (humble apologies if it was here
instead.) If the intent is to block executables in archives, best to
detect ALL archives and ALL executables. Not all zipped
executables are viruses (!), nor are all viruses executables (well,
not those the best-known extensions anyhow). For example, I would think
.msi should be of concern.
[...] If you're in the business of exchanging program binaries with
people (oh, say, because you're a software developer), this
particular quarantining method may impact your ability to exchange
files with people, since you'll lose the ability to receive
executables within ZIP files (which has for a long time been the
standard way to exchange binaries without risking them to discarding
by generic malware checks).
In all fairness, that is a limitation of ALL policy-based approaches. If
poorly implemented, a policy (whether you call it a formal policy or
not) can hinder business.
If you run your own show, you can do whatever you want. But if you're a
hapless IT type trying to fix one problem (Bryan didn't indicate either
way), you'd best make sure you don't create a larger problem. Not to
preach but: "Security implementation should be a reflection of policy."
Unless the official policy is NO ZIP or EXECUTABLE ATTACHMENTS,
implementing a tool that simply blocks such things -- whatever you call
it -- is definitely a career-limiting move. However, IF that IS the
policy, then it's a simple and very effective approach. Definitely not a
one-size-fits-all solution though!
[...] Possible (though klunky) workarounds include:
[...] * at least as far as the incarnation of the softlabs filter I
examined, you could ensure that the FIRST file in the zip was
something other than an executable binary, since the recipe seemed to
examine just the first zipfile entry.
Am I mistaken, or won't simply renaming the zip before sending suffice
to bypass the current incarnation? Awkward for a human sender, sure. An
ideal way to defeat rudimentary filters for a worm, however. (Again, in
all fairness, several defang/filter products share this limitation.)
The maxim of security is "that which is not explicitly allowed should be
denied." So... OK, I was going to say the p-word again... I'm thinking a
good approach would be:
1. Only files types of [... your list of extensions here ...] will be
allowed as email attachments.
2. All files with unapproved extensions will be summarily deleted. <-
procmail is perfect here. no stupid auto-responders, please!
3. Any files named with an approved extension will be subjected to
verification. (see 'man file'). <- procmail
a. Files with names/extensions not matching the actual content will be
(dropped|quarantined). <- procmail + file + ?
b. Any files that match the indicated type and are of the approved type
will be (scanned with [... insert approved heuristic scanner
...]|quarantined in /path). <- procmail + sanitizer/defanger of choice
3. Recipients will bear ultimate responsibility for taking reasonable
and prudent measures [HR approves this part] for verifying the
authenticity of any files passing the process described above, and will
be held responsible for any damages caused by installing, running or
viewing files from unknown sources. [In my world, I'd add pgp-signature
requirements as a "reasonable and prudent" measure to verify
authenticity.] <- a big hammer and the fist of God helps here
[...] if your senders are adding this, they could just as easily be
added to a sender greenlist.
[...] * Similar to the above, one could require that desired files
be sent
within PGP-signed messages. The filter could check for good
signage
and allow passage when the message is from a recognized sender.
Oooh. I recall reading a recipe in a HOWTO on automatically retrieving
PGP keys via procmail. OK, how far are we from:
If messsage has attachment AND PGP signature attached
retrieve key and verify authenticity
else
drop/quarantine
Intrusive in that senders must sign, but then again, I would think
coders are a bit used to such things by now. If policy is:
1. Only attachments that are PGP-signed (encrypted?) will be opened.
Now life sure has become easier for all concerned. Practice rudimentary
key control, and it's safe... for us at least. Signing/encrypting
messages is pretty much a 1 click operation with PGP add-ons these days.
With other privacy concerns these days, it's not a bad measure anyhow
(at least while it's still legal.) No dopey "you sent a virus" messages,
nor confirmation from the sender required. An existing, robust solution
(PGP) lets us verify the sender with very high degree of confidence. If
they can be trusted to do basic things like passphrase protect their
keys, and we back this up with a local scan with a "proper" virus
scanner, the risks drop considerably.
Both of the last options place a software burden on the sender, and
also require the (presumed to be /etc/procmailrc invoked) filter to
support per-user databases (you could implement them site-wide, but
that just seems wrong, IMO).
If run with DROPPRIVS=yes, procmail could work with receiving user's
keychain, no?
OK... procmail seems to be ideal for much/most of this. I'm getting
inspired to try my hand at it. Procmail + PGP signatures (with or
without encryption) to verify autheticity is something I'd be very
interested in.
- Bob
_______________________________________________
procmail mailing list
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail