Enhancing E-Mail Security With Procmail

Latest News

Email-based Attacks

There are four types of attacks on system security that can be carried out via electronic mail:

Browser attacks, which take advantage of various active HTML and scripting features and bugs.
Buffer Overflow attacks, where the attacker sends something that is too large to fit into a fixed-size memory buffer in the email client, in the hopes that the part that doesn't fit will overwrite critical information rather than being safely discarded.
Trojan Horse attacks, where an executable program or macro-language script that grants access, causes damage, or does other unwelcome things is mailed to the victim as a file attachment labeled as something innocuous, such as a greeting card or screen saver, or hidden in something the victim is expecting, such as a spreadsheet or important document.
Shell Script attacks, where a fragment of a Unix shell script is included in the message headers in the hopes that an improperly-configured Unix mail client will execute the commands.

Browser Attacks, a.k.a. Active HTML Attacks or Scripting Attacks

These attacks are aimed at people who use a web browser or HTML-enabled email client to read their email, which these days is a very large portion of the computing community. Typically these attacks attempt to use the scripting features of HTML or of the email client to retrieve private information from the victim's computer or to execute code on the victim's computer without the victim's consent (and possibly without the victim's knowledge).

Less dangerous forms of these attacks can automatically cause the recipient's computer to display some content the attacker wishes, such as automatically opening an advertising or pornography web page when the message is opened, or perform a Denial-of-Service attack on the recipient's computer through code that freezes or crashes the browser or the entire computer.

The simplest way to completely avoid such attacks is to not use a web browser or HTML-enabled email client to read your email. Since many of these attacks do not depend on bugs in the email client software, they cannot be prevented through patches to the email client. If you use a web browser or HTML-aware email client, you will be vulnerable to these kinds of attacks.

Also, as some of these attack depend on the email client being able to execute scripted HTML rather than depending on the weaknesses of any particular operating system, these attacks can be cross-platform. An HTML-enabled email client on a Macintosh is just as vulnerable to active-HTML email attacks as an HTML-enabled email client on Windows or Unix. The vulnerabilty will vary from system to system based on the email client rather than the operating system.

Switching to a non-HTML-aware email client is not a realistic option for many people. An alternative is to filter out or alter the offending HTML or script code before the email client gets a chance to execute it. It may also be possible to configure your email client to turn off the interpretation of script code. See your program documentation for details. Turning off scripting in your email client is strongly recommended. There is very little reason to support scripted email messages.

The recently-announced Outlook email worms are an example of this attack. See the Bugtraq Vulnerability database for more details.

Buffer Overflow Attacks

These attacks can be used as Denial-of-Service attacks, because when a program's memory gets randomly overwritten the program will generally crash. However, by carefully crafting the exact contents of what overflows the buffer, it is in some cases possible to supply program instructions for the victim's computer to execute. The attacker is mailing a program to the victim, and it will be executed by the victim's computer.

Note that this is the result of a bug in the program under attack. A properly written email client will not allow random strangers to run programs on your computer without your consent. Programs subject to buffer overflows are incorrectly written and must be patched to permanently correct the problem.

Buffer overflows in mail programs occur in handling the message headers and attachment headers, which is information the email client needs to process in order to know details about the message and what to do with it. The text in the body of the message, which is simply displayed on the screen and which is expected to be a large amount of text, is not used as the vehicle for buffer overflow attacks.

The recently-announced overflow bugs in Outlook, Outlook Express and Netscape Mail are examples of this. Patches for Outlook are available via the Microsoft security site. Netscape Mail versions 4.06 and later have had this bug fixed.

The message headers and attachment headers can be preprocessed by the mail server to limit their lengths to safe values. Doing this will prevent them being used to attack the email client.

Trojan Horse Attacks

These attacks are usually used to breach security by getting a trusted user to run a program that grants access to an untrusted user, or to cause damage such as attempting to erase all of the files on the victim's hard disk. Trojan Horses can also act to steal information or resources or implement a distributed attack, such as by distributing a program that attempts to steal passwords or other security information, or a program that mails itself around (a "worm") and also mailbombs a target (a worm with an attitude :).

For this attack to succeed the victim must take action to run the program that they've received.

This attack can be avoided simply by not running programs that have been received in email until they have been checked over, even if the program seems to be harmless and especially if it comes from someone you don't know well and trust.

Except...

Bugs in the email client may allow the attack message to automatically execute the Trojan Horse attachment without user intervention, through either the use of active HTML, scripting or buffer overflow exploits. This is an extremely dangerous scenario and is becoming more and more likely every day.

In an attempt to prevent this, the names of executable file attachments can be changed in such a way that the operating system no longer thinks they are executable (for example, by changing "EXPLOIT.EXE" to "EXPLOIT.DEFANGED-EXE". This will force the user to save and rename the file before it can be executed (giving them a chance to think about whether it should be executed), and it reduces the possibility that other exploits in the same message will be able to find and execute the Trojan Horse program automatically (since the name has changed).

In addition, for known Trojan Horse programs the attachment format can be mangled in such a way that the email client no longer sees the attachment as an attachment. This will force the user to contact technical support to retrieve the attachment, and gives the system administrator a chance to examine it. Here is a list of recent Trojan Horse executables and documents, gleaned from bugtraq and Usenet newsgroup warnings and antivirus vendor advisories:

*.hta *.shs *.vbs *.hlp *.chm babylonia.exe buhh.exe chocolate.exe i-watch-u.exe jesus.exe serialz.hlp surprise!.exe x-mas.exe badass.exe story.doc suppl.doc y2kcount.exe setup.exe monopoly.vbs zipped_files.exe prettypark.exe pretty park.exe path.xls compu_ma.exe list.doc photos17.exe happy99.exe IBMls.exe picture.exe yahoo.exe ie0199.exe aol4free.com

Another channel for Trojan Horse attacks is via a data file for a program that provides a macro (programming) language, for example, modern high-powered word processors, spreadsheets, and user database tools.

If you cannot simply discard attachments that may put you at risk, it is recommended that you install anti-virus software (which detects and removes macro-language Trojan Horses) and that you always open data file attachments in the program's "do not automatically execute macros" mode (for example, by holding down the [SHIFT] key when double-clicking the attachment).

Note: Windows NT CMD.EXE apparently only assigns special meaning to the .BAT and .CMD extensions, knowing that they are probably scripts. It will happily run a .EXE-format program that's named, for instance, BLAH.GIF. It's unfortunate that CMD.EXE does not behave consistently with the graphical shell.

Also: if your system administrator (or someone claiming to be your system administrator) emails you a program and asks you to run it, immediately become very suspicious and verify the origin of the email by contacting your administrator directly.

Shell Script Attacks

Many programs running under Unix and similar operating systems support the ability to embed short shell scripts (sequences of commands similar to batch files under DOS) in their configuration files. This is a common way to allow the flexible extension of their capabilities.

Some mail-processing programs improperly extend this support for embedded shell commands to the messages they are processing. Generally this capability is included by mistake, by calling a shell script taken from the configuration file to process the text of some headers. If the header is specially-formatted and contains shell commands, it is possible that those shell commands will get executed as well. This can be prevented by the program scanning the header text for the special formatting and changing that formatting before it gets passed to the shell for further processing.

Since the formatting needed to embed a shell script in an email header is fairly special, it's fairly easy to detect and alter.

Filtering Email for Security

(Finally! The meat!)

Procmail is a program that processes email messages looking for particular information in the headers or body of each message, and takes actions based on what it finds. If you're familiar with the concept of "rules" as provided in many major user mail clients (such as the cc:Mail client), then you are already familiar with the concept of automatically processing email messages based on their content.

This page provides you with a procmail ruleset specifically designed to "sanitize" your email against these attacks.

Personal safety

Please see my Procmail Kit page for details about how to use procmail, and a kit of rules that includes the sanitizing ruleset as well as anti-spam filters. If you just want to sanitize your email and don't care about spam, then you can download and install just the sanitizing ruleset. Note that the full kit may have an older version of the sanitizing filter.

The ruleset

The email security procmail ruleset is available at:
[ FTP Mirror 1 (USA: UT) | FTP Mirror 2 (Europe: NL) | HTTP Mirror 1 (USA: WA) | HTTP Mirror 2 (USA: CA) ]

If you are downloading this on a Windows system for use on a Unix or Linux system, make sure that you take care of text-file conversion - the script will not run properly with DOS end-of-line characters in it. One way to do this is to open the sanitizer script in vi and type:

:textmode on :textmode off :wq

Site Safety

If you're an administrator and you wish to sanitize all of your users' email automatically, here's how to do it:

Requirements

Your email must be received by a system that runs or can run procmail. See the procmail link above for information about obtaining and installing procmail for your platform.
If you are running sendmail then it must be set up to use procmail as the local delivery agent. Look for the following line in your /etc/sendmail.cf file:
```
  Mlocal,    P=/usr/bin/procmail, F=lsDFMAw5:/|@qSPfhn9, S=10/30, R=20/40,
             A=procmail -Y -a $h -d $u
```
To install these sanitizing rules on a sendmail hub, follow the directions given on the procmail man page and generalize the directions given below.
You must have perl installed.
If you wish to scan attachments, you must have mimencode (which is a part of the metamail package) and mktemp installed. I have decided that Mime::Base64 from CPAN is better for this, so sometime soon the sanitizer will use that instead of mimencode.

Installation under nix and workalikes (Linux, BSD, etc.)

Create a directory /etc/procmail owner and group root, permissions rwxr-xr-x.
Download the sanitizing ruleset and save it in that directory, owner and group root, permissions rw-r--r--. If you are using Lynx, highlight the above link and press "D" to download the file - don't view it and save it, it'll be corrupted.
Create /etc/procmailrc owner and group root, permissions rw-r--r-- and put the following into it:
DROPPRIVS=YES LOGFILE=$HOME/procmail.log PATH="/usr/bin:$PATH" SHELL=/bin/sh POISONED_EXECUTABLES=/etc/procmail/poisoned SECURITY_NOTIFY="postmaster, security-dude" SECURITY_NOTIFY_VERBOSE="virus-checker" SECURITY_QUARANTINE=/var/spool/mail/security POISONED_SCORE=25 SCORE_HISTORY=/var/log/macro-scanner-scores # Finished setting up, now run the sanitizer... INCLUDERC=/etc/procmail/html-trap.procmail # Reset some things to avoid leaking info to # the users... POISONED_EXECUTABLES= SECURITY_NOTIFY= SECURITY_NOTIFY_VERBOSE= SECURITY_QUARANTINE=

Of course, if you've already got an /etc/procmailrc file you'll have to incorporate the INCLUDERC=/etc/procmail/html-trap.procmail call into what's already there.
Notes about local policy:
This will create a file named procmail.log in the home directory of any user who receives mail. Your users should be instructed to periodically review and delete this file, or an administrative daemon should be set up to periodically collect statistics and delete the files or warn the user to do so. If you don't care to log the sanitizing messages and possible exploit warnings, then change the logfile line to:
LOGFILE=/dev/null

Note that the DROPPRIVS at the beginning means the log file must be writable by the recipient.
If you wish to block specific executable and document attachments, create a text file containing one filename or filespec per line, with no comments or leading spaces, and set the variable POISONED_EXECUTABLES to point at that file before calling html-trap.procmail. See above for a recommended list of filenames of known trojans. The names in this list are not case-sensitive and wildcards may be used.
If you wish to be notified when the filter traps poisoned attachments, set SECURITY_NOTIFY and/or SECURITY_NOTIFY_VERBOSE to a comma-delimited list of email addresses to notify. The SECURITY_NOTIFY_VERBOSE recipients will receive a full copy of the message, the SECURITY_NOTIFY recipents will only receive the headers.
If you wish to quarantine poisoned messages, set SECURITY_QUARANTINE to the file you wish to save the message in. This will prevent delivery to the original addressees. It is suggested that you set SECURITY_NOTIFY if you set SECURITY_QUARANTINE as this will remind you to check the quarantine file.
Note that the DROPPRIVS at the beginning means that the security quarantine file must be writable by users. If this is a problem, you may want to try setting the quarantine filename to /dev/null and rely on SECURITY_NOTIFY_VERBOSE to keep a copy of the original message.
The sanitizer implements a scanner which checks Microsoft document and worksheet attachments for macros that appear to be trying to do dangerous things. Depending on what the macros in a document or worksheet try to do, you may see false positives (safe documents being marked as dangerous). The score at which an attachment is considered "poisoned" may be set via POISONED_SCORE. If not given, it defaults to 10. The minimum POISONED_SCORE is 5. I recommend 25.
If you wish to completely disable macro scanning, set DISABLE_MACRO_CHECK to any value. If you wish to scan and save the scores to do profiling but not mark any attachments as "poisoned", you can either set SCORE_ONLY to any value (not recommended), or set POISONED_SCORE to a very high value (100-200 is recommended - this will trap currently known exploits while giving you a chance to profile). Set SCORE_HISTORY to the name of the file to save scores in (with the same DROPPRIVS caveats as the other log files).
All of these site policy customizations must be made in the procmail script that calls the sanitizer, before the sanitizer is called, or they will have no effect.
Suggestions for what to consider dangerous in a macro are welcome, as are samples of infected documents.

News & Notes

The current version of the html-trap.procmail ruleset is: 1.102
It is recommended you update your copy if your version is older, as bugfixes and filtering for newer exploits will have been added.

An announce list for email security issues has been set up. It will primarily carry information on new exploits and updates of the sanitizer. To subscribe, send a message with the subject "subscribe" to esa-l-request@spconnect.com.

03/26/00 Added ".eml" to the executable extensions list. Dynamic configuration of this soon...

02/01/00 Improved handling of quotes in tag arguments.

01/22/00 Sanitizer now deals with attempted obscuration of tag options with &# and % escapes.

01/14/00 Fixed another DoS bug in certain quoted strings, and generally improved quoted string and wrapped-header handling.

01/09/00 Added ".chm" to the executable extensions list. Compiled Help files are just a vulnerable as uncompiled Help files.
Added defanging of javascript and other scripting languages embedded in IMG SRC= and other tags. This is actively being exploited on Hotmail. Thanks to Georgi Guninski.
Fixed another DoS bug in international character set quoted-illegible filenames.

12/11/99 Added ".hlp" to the executable extensions list. Somehow it's possible to script Microsoft help files.

11/09/99 Fixed another DoS bug, this one tickled by MIME filenames containing certain Perl regular expression characters - for example, filename="file (1).exe" would cause an infinite loop.

10/31/99 Yet another Microsoft executable filename extension attack. See this advisory for details about .SHS trojans.

10/12/99 Added Perl .PL and PowerPoint .POT extensions to executable attachments processing. (This will soon be easily site-customizable.)
(oops!) Fixed DoS bug for MIME headers with multiple "name=" clauses. Apparently Z-Mail 3.2.1 is generating somewhat iffy MIME headers...

08/28/99 Added wildcard support to the poisoned-filename list. The syntax is a cross between shell-filespec syntax and Perl RE syntax. Some examples:

*.hta *.vbs happy??.exe happy[0-9]+.exe

08/18/99 Added trap for the ODBC remote shell exploit. Note that this may not catch all possible variants of this exploit. See the bugtraq vulnerabilities database for more details. (NB: this also renders the "no signature files" comment below a little less true. Oh, well.)

08/10/99 Sigh. Yet more Microsoft macro languages that can be exploited via email. Added support for poisoning .HTA and .VBS attachments.

06/12/99 Improved javascript defanger - events such as OnLoad= are now directly recognized. Defanging them individually is better than tossing <TITLE> and <BODY> tags in toto, and also protects links (which wasn't happening before).

04/02/99 Scanning of Word documents and Excel worksheets for possibly hostile macros seems to work acceptably well, so I'm going to release it. Note that this does not scan for variant-specific strings, so there aren't any "signature files" involved, but this means that it is possible to get false positives on complex macros. You may want to profile for a while before turning on macro-based attachment poisoning.

Troubleshooting

If you get "Word too long" errors, try adding "SHELL=/bin/sh" or "SHELL=/bin/ksh" to /etc/procmailrc just before the call to html-trap.procmail - csh can't handle a command-line argument the size of the Perl script that's in the filter.

Do not put html-trap.procmail into /etc/procmailrcs/ as implied by the procmail man page. You'll get security errors from Perl about -e and setuid scripts if you do this. You may also have problems with filtering mail sent to root for this reason.

You'll also get setuid script errors from Perl if you omit the DROPPRIVS=YES from the script that calls the sanitizer.

It looks like this perl script can be a bit of a memory hog on some systems. If you start getting "Out of memory" errors in your procmail log file, try adding

ulimit -d 15000;

just before the perl -p -e in the MIME-sanitizing rule:

:0 fw | ulimit -d 15000; perl -p -e ' #\

You might also have to increase the hard memory limit originally set for sendmail.

I can be contacted at <jhardin@wolfenet.com> - you could also visit my home page.

Best viewed with Any Browser