Realtime Worm Filtering System

Doesn't this already exist in the form of anti-virus companies and automatic filter updates? Several firewall vendors support pre-screening of email through a vendor-delivered filtering backend, and most mail server backends support some form of bolting up to an existing virus-checking system. So, how does this proposal differ from the current scheme, other than reduce the cost to the administrator?

I think one of the biggest advantages of a system of this nature is that it would save a lot of system overhead. I remember back when I ran a BBS in the early 90s, it was a little overwhelming for my system (an 8086) to unzip and virus-scan every upload. Though we've obviously seen a considerably advance in processor power, I still shudder at the thought of unzipping, untarring, ungzipping, un-Stuffing, uudecoding, etc., attachments to all incoming mail to run a full virus scan on every one. Some of my mail servers, I imagine, would gurgle, choke, and then die a horrible death at the hands of such abuse. (The POP and IMAP users, on the other hand, would be positively sterile, which I love the idea of.)

There's also -- as you pointed out, logic -- the issue of cost. Free beer is good. Then there's free speech -- I also prefer not to rely on a corporation for black-box virus/worm updates. Given Symantec's patent on virus updates, I'm a little skiddish about the whole anti-virus industry. A community effort is, to me, quite preferable.

I did some quick research on this yesterday, since I had some users who are [too trusting | too desperate for pictures of tennis stars ]. Warning: I am not a sendmail guru, and procmail is on my list of "ought to learn this someday."

My first thought was that this sounds like something sendmail ought to handle, right? There ought to be some line-noise-like command in sendmail.cf that will filter on MIME type. Unfortunately, this turns out not to be true -- sendmail's classic behavior is to concentrate on delivery, not content. A content-filtering API (libmilter) was added in sendmail 8.10, and the API was changed in 8.11. While this capability now exists, many mail systems are still on 8.9 and earlier and will not be able to take advantage of sendmail filtering. Also, this is simply an API, and so relies on other offerings like vbsfilter to actually perform the filtering.

The alternative solution is to set up procmail as the local mailer, and do this filtering via procmail rules. The most mature-seeming procmail recipe for this that I was able to find is the Procmail E-Mail Sanitizer, which "defangs" files based on a list of executable types [*.vbs, *.exe, *.dll, etc.], plus some well-know .zip worms. It also claims to have some rudimentary support for scanning Microsoft Office files for macro virii. I hope to give this a try Real Soon Now(tm).

As for Waldo's concern about mailserver load, the beauty of the E-Mail Sanitizer approach is that it offloads virus scanning onto the PC client, and if no one sends files in Microsoft Office formats, the macro virus scanning will never be invoked either. :^)

Does anyone have experience (good or bad) with the sendmail/procmail combinaition, or the E-Mail Sanitizer in particular?

We already have a real-time worm filtering system: people. The problem is one of education. People should know better than to have any sort of automatic action triggered by reading their email. Mail client writers should know better than to have default actions for certain types of email. Mail client writers should also provide safety mechanisms that shield users from potential danger.

Also, there's good 'old signing. If that were to become more widespread then people wouldn't be fooled into trusting an email just because it appears to come from someone they know.

All I'm saying is solve the problem, not the symptom.

At my job, we do behavioral analysis measurement of running software.

One of the things that I've learned from the measurement tools we've built, and from measuring software's behavior as it runs, is that the problem of email worms can be avoided.

When a person is using Outlook (or whatever email client), the program doesn't normally start shipping messages out to everybody in the addressbook.

Recognizing and stopping this type of anomaly is really pretty easy. But, people don't build software with the sensors necessary to observe the actual internal behavior of the system. Physical systems are built this way (strain gauges, pressure sensors, temp sensors, etc.), and the important ones (airplanes, satelites, HVAC, etc.) are able to respond somewhat gracefully to abnormal behavior. Software on the other hand, just tends to make a mess of its house and home.

duff: How would digital signatures help? After all, a worm of this type is sending mail as the user, so there's no reason the generated spam wouldn't have a perfectly valid digital signature attached.

ztf: I think duff was implying that people getting into the habit of digitally signing - with a password-protected signing key - would dampen these worms since the mail a worm would generate (unless it felt like asking for your password) would not be signed.

Waldo - I think your point about antivirus software - how the threat of polymorphic viruses as a result of a/v software was vastly overestimated - is a very good one, but I don't know how well it applies to email worms. Look at Anna, it appears to have been generated by a kiddie who couldn't even code VBS and auto-generated the script. To have such an auto-generator alter topics, content, and whitespace in the script attachment would be trivial, and would defeat most simple attribute-matching heuristics, in addition to filling any such databases with a lot of noise. Seems we are better, with md5 sums and such, at detecting change than at detecting consistency.

Instead, I would agree with happybob's assessment - this oughta be handled by the client software, because it should perceive there to be a problem when it starts spontaneously spewing dozens of messages. Even simple heuristics at the client level might solve a lot of problems by simply limiting the massive email floods that cripple everyone when one of these comes along.

Anyhow, just some random Dr. Pepper inspired thoughts. Good article.

duff is correct, we need to nip this is the bud with education, but there are parts of MS that could improve in this department.

One would be making sure that the exensiont may not be what they seem. When it's a vbs script file say, this script could be mallicious, it could format your hard drive, are you sure you want to run it?" And make users take a more active roll. Part of this whole problem was because microsoft didn't quite decided how to parse the filement for mime-type autolaunch things.

Though, I guess I'm special in that I don't interact with many people who are on windows boxes, and those that are, use Netscape. I have yet to recieve a single one sent directly to me! I wonder if someone's going to send me one just to be funny. :)

It really does come to more strick warmnings and user education.

*shivers and thinks about when you can have vbs auto sign your emails for you because you didn't set a passphrase on it*

If there is a lesson that can be learned from computer security, it is that you can't solve social problems technically. If people chose to use broken software with inherent virus and worm problems, you can't to anything about it.

Trying is a waste of time. The problem will solve itself in time.

Outlook already costs the world more money than web defacements, break-ins to credit card databases and other hazards. Companies that are too dense to see the real problem (Outlook) will go bankrupt. The market will handle it. This is not an education issue. There is no reason why people should not be allowed to clock on attachments. Allowing that is the function of email clients, after all!

May Outlook rest in peaces.

Outlook has so many mechanisms for running untrusted code because it's displaying messages using the same engine that display folders on the desktop. Not just the interpreter, the whole thing, active content handlers and all. Then to "protect" you it filters out certain types of content... now then, does anyone run a "default allow" firewall on their network? No?