%META:TOPICINFO{author="chris.lowth" date="1025375700" format="1.0" version="1.1"}% %META:TOPICPARENT{name="Documents"}%

Using protector 1.01

NB: This page is currently incomplete and out of date

Author: Chris Lowth, (protector@lowth.com)
Date: April 2001

Functional overview

The protector program inserts itself (on installation) into the local mail delivery chain in a linux box equipped with either sendmail or postfix, and procmail.

Every mail message that is delivered to a local user (including POP3 users of connected windows (etc) systems) of the system is piped through the protector program before being passed on to "procmail" for actual delivery to the recipient user. Protector scans the mail message for attachments, and passes each one it finds to a "part_filter" program for approval. This program checks the type of file contained in the attachment, and typically verifies that it is incapable of containing viruses, worms or other undesirable content. It does not (currently) perform a virus scan, but simply rejects file types that could contain viruses. Examples of rejected file types are..

• DOS (windows) executable (.exe, .com etc) files
• visual basic files (.vba)
• Microsoft word documents that contain macros
• ... etc ...

For safety, the part_filter does not (logically) contain a list of types it will reject, but a list of types it will accept. This means that files of unknown (or: as yet un-handled) types dont get through. This "better safe than sorry" logic is deliberate, and means that the author and users alike dont have to play the continual "catchup" game that tradition virus scanning software requires.

The part_filter program is actually a perl script - making it (relatively) easy for systems administrators to modify the rules used to accept or reject mail attachments. The script can even be modified by sysadms who are not familiar with perl because every effort has been made to make the script easy to modify. Configuration information (such as the lists of attachment types to allow through) is placed in easy-to-modify tables at the top of the script.

When the part_filter rejects an attachment, it replaces it with a warning message that describes the reason for the rejection, and archives a copy of the attachment (still encoded) in the directory /var/protector/rejects. The system administrator (root) can gain access to this archive (using the "revive" utility) in order to pass it on to the original recipient, if he/she manages to verify it's safety "manually".

The recipient of the mail message is alerted to the fact that protector has modified his (or her) e-mail, by a message like this in the mail..

    --- Warning message from your e-mail system's virus checker ---

    DISALLOWED TYPE

    This email contained an attachment of an "illegal" or "dangerous"
    type, so the system has replaced it with this warning message.

    This may seem like a nuisance, but please understand that it is in
    your own interests to avoid accessing email message attachments
    that contain viruses. Since it hasnt been possible to check this
    message for actual viruses, the server has taken the pessimistic
    but safe view that you are better off without it.

    If it is important that you are able to view the attachment, please
    speak to your system administrator, and ask for assistance. I will
    keep a copy of the original attachment in a "safe" place for a few
    days. You cannot access this "safe" folder, but your system
    administrator can - so speak to him (or her) about it. It would be
    appreciated if you dont ask for help in gaining access to cartoon
    animations and other "joke" files - keep the requests for help for
    real "important" stuff.

        Content-type: Application/Octet-stream; name="b15may00.doc"; type=Unknown
        Content-disposition: attachment; filename="b15may00.doc"
        Content-transfer-encoding: BASE64
        X-Discovered-Type: unknown/unknown
        X-Copy-Of-Original: 20000529.093015.1

At the tail end of this message, the attachment header fields are listed along with two new header fields generated by the part_filter itself.

• X-Discovered-Type contains the mime type of the attachment, as determined by the part_filter and it's helpers (its there as a debugging aid).
• X-Copy-Of-Original is the name that the archive copy of the file has been given, when stored in the /var/protector/rejects directory.

Currently, the system does NOT automatically alert the sender of the mail message to the fact that his mail attachment has been rejected - this option will follow in a future release.

Current approval logic

The current version of protector allows attachments of the following types through, and rejects all others. ( NB: This list is incomplete )

• Raw text files (mime type text/*)
• Files compressed with GZIP or BZIP2 - provided that the uncompressed file is also valid. Decompression is performed recursively, so you cant fool the system by sending a .exe file in a GZIPPED, BZIP2'ed file (for example).
• Files contained in TAR or ZIP archives - provided that the unzipped files are also valid (see note above about recursive decompression).
• Multi media files of types image/*, audio/* and video/*.
• E-Mail notification mails (sub-attachments are also submitted back to protector for re-approval) of types message/disposition-notification, message/delivery-status and message/rfc822.
• MS Word documents, Excel worksheets, powerpoint documents and MS office binders, provided they don't contain macros.
• RTF files that don't contain attachments.
• MS-Tnef mails provided any attachment is also "safe".
• Unix 5.4 (and UnixWare 2.1) package data streams. Why include this one in an early release? Simple: I use them a lot!

In time, other types will be added to the "allowed through" list - particularly as users and developers assist me by sending me logic fragments for handling them (see below).

Microsoft Office file validation

Files from the Microsoft office suite of software are among the most commonly attached files in internet e-mails, but they are also amongst some of the most dangerous because they can contain macros or scripts that can be executed on the receiving user's machine without his permission or knowledge. Not surprisingly, these file formats have become prime targets for virus developers.

Protector includes logic for decoding a subset of these files, and validating them for safety. The basic rule of validation is "it's safe as long as it doesn't contain macros, or embedded objects that could contain macros". The "check_msole" module understands the basic format of OLE documents (which is the format used by MS office files), and is capable of checking for macros in Word, Excel, Powerpoint and Binder files (amoungst others). Further, the program checks for embedded objects and verifies that they too are safe. Following protector's core philosophy, the program has a list of embedded object types that are "safe", and flags all others as potentially dangerous. Luckily the set of safe objects includes the majority of the most commonly occurring ones.

In writing the "check_msole" program, I have made extensive use of knowledge gleaned by reading the source code of OpenOffice (the open sourced version of Star Office), MSWordView and Laola.

Help wanted

In developing a product such as this, I am limited to working with the types of files that I and my immediate circle of users routinely see. If the product is to find wider acceptance, the library of "accepted" file types needs to grow. If you are a developer or systems administrator with enough understanding to add to the list of "accepted" types yourself, please will you send me the results of your work so that I can include them in a future release for others to enjoy. The only rules I impose here are..

• That you accept that your code will be released under the terms of the GNU public licence - and that you follow those terms yourself - particularly if you "borrow" code from others.
• That you accept that I may submit your code to public scrutiny (in the form of a alpha or beta release) before "going official" with it, and may choose not to include in a release for what ever reason I wish (this will usually be because of security or other "holes" in the logic, which I will enter into discussion with you about before making my final descision).