renattach 1.2.0rc1 - Filter that renames/deletes dangerous email attachments

I would like to announce this pre-release (RC1) of my software. I have
been in contact with many mail admins from around the world and have
spent the last few months developing the 1.2.0 series (a complete
rewrite). I would appreciate any feedback, of course! This is released
under the GNU GPL.

------------------
renattach 1.2.0rc1 - http://www.pc-tools.net/unix/renattach/
Filter that renames/deletes dangerous email attachments

renattach is a stream filter that can identify and act upon potentially
dangerous e-mail attachments. It's a highly effective way of protecting
users from harmful mail content (virus/worms) by disabling or removing
attachments that may be accidentally executed by the user.

renattach is written in pure C and can quickly process mail with little
overhead. Unlike a conventional virus scanner, there are no specific
virus or worm definitions. Instead, renattach identifies potentially
dangerous attachments based on filename extension and on encoded body
content. The filter reads the incoming email from stdin and writes the
filtered result to stdout while renaming, deleting, or even killing
(absorbing) the suspect message. It is a flexible mail tool that can be
used from within sendmail, postfix, procmail, or pretty much anywhere
else.

Tested under Linux, Solaris, and Mac OS X (Darwin). This software should
compile on any UNIX-like system that has standard C libraries.

FEATURES:

* Fast, lightweight, little overhead
* Recognizes both MIME and uuencoded attachments
* Compliant with RFC2047 and RFC2231, handles encoded filenames
* Can rename or delete attachments, or kill entire messages
* Can detect executables by DOS/Windows signature
* Accepts list of specifically banned filenames (great for handling
floods)

--
Jem Berkes
http://www.sysdesign.ca/

"Jem Berkes" <jem@users.pc9__org> wrote in message
news:Xns941F917CE6151jbuserspc9org@205.200.16.73.. .
> I would like to announce this pre-release (RC1) of my software. I have
> been in contact with many mail admins from around the world and have
> spent the last few months developing the 1.2.0 series (a complete
> rewrite). I would appreciate any feedback, of course! This is released
> under the GNU GPL.
>
> ------------------
> renattach 1.2.0rc1 - http://www.pc-tools.net/unix/renattach/
> Filter that renames/deletes dangerous email attachments
>
> renattach is a stream filter that can identify and act upon potentially
> dangerous e-mail attachments. It's a highly effective way of protecting
> users from harmful mail content (virus/worms) by disabling or removing
> attachments that may be accidentally executed by the user.
>
> renattach is written in pure C and can quickly process mail with little
> overhead. Unlike a conventional virus scanner, there are no specific
> virus or worm definitions. Instead, renattach identifies potentially
> dangerous attachments based on filename extension and on encoded body
> content. The filter reads the incoming email from stdin and writes the
> filtered result to stdout while renaming, deleting, or even killing
> (absorbing) the suspect message. It is a flexible mail tool that can be
> used from within sendmail, postfix, procmail, or pretty much anywhere
> else.

Why is this any better than "sanitizer", at
http://www.impsec.org/email-tools/pr...security.html? That was written
in perl, is quite portable and is easily integrated to any procmail capable
Mail Transport Agent?

If your tool has some cool new feature or features, great. If it's
considerably faster or lighter weight, also great. But otherwise, why should
we use yet another of the dozens of mail-filter programs published, and
worse yet work with a beta release that hasn't been put through the
trial-by-fire of popular usage?

> Why is this any better than "sanitizer", at
> http://www.impsec.org/email-tools/pr...security.html? That was
> written in perl, is quite portable and is easily integrated to any
> procmail capable Mail Transport Agent?

Gosh, you already know the main answer to that. It's good to have choice!
And different software has different strengths.

Details... renattach is considerably faster. There's a world of
difference in the processing overhead between compiled C, and a huge perl
script that has to be interpreted on each message.

Also, the intent of the filter is different. While theirs uses various
signature and custom rules, mine essentially parses filenames and looks
at the file extensions of attachments. Bad file extension, and the mail
is acted upon. Also, ANY executable attachment (hunting for 'MZ' exe
identifier) can be matched. No definitions, no update hassles.

Mine supports all sorts of encoded filenames, including RFC 2231 and RFC
2047. Very few other similar filtering solutions bother to do this.

My software is a generic stdin/stdout filter and can easily be embedded
into many systems. There is nothing procmail-specific about it.

Because my software is fast, it may be the only reasonable way to handle
a serious worm flood on a busy server. I know admins were telling me that
other virus scanners were driving up their load averages to peak, during
swen and earlier floods.

> If your tool has some cool new feature or features, great. If it's
> considerably faster or lighter weight, also great.

Great on those two counts, then.

> ... and worse yet work with a beta release that hasn't been put
> through the trial-by-fire of popular usage?

Renattach has been used by the Medical University of South Carolina and
the University of Ferrara (Italy) for over a year. I also keep in touch
with a couple other mail admins that use it on their servers that support
a few dozen users each. It is * not * untested.

The ONLY worm to date my software has missed has been a variant of gibe.
This is the first update I've had to make in exactly two years.

--
Jem Berkes
http://www.sysdesign.ca/

Jem Berkes spilled the following:

>> ... and worse yet work with a beta release that hasn't been put
>> through the trial-by-fire of popular usage?
>
> Renattach has been used by the Medical University of South Carolina and
> the University of Ferrara (Italy) for over a year. I also keep in touch
> with a couple other mail admins that use it on their servers that support
> a few dozen users each. It is * not * untested.
>
> The ONLY worm to date my software has missed has been a variant of gibe.
> This is the first update I've had to make in exactly two years.

I've used it on a site with roughly 100 users for about 4 years, Loved it.
When I first got it, it didn't do procmail, but re-writing the code to
accomodate this was very easy. ISR that there were also some cases of
malformed MIME attachments identified at that stage too.

I've recently changed employer; the mail system I look after now is rather
different, but I'm planning on getting renattach installed there too.

Jem does warn that this is a release candidate version, based on a complete
rewrite, I've yet to see it but would be surprised if it's less polished
than previous versions.

Colin McKinnon

"Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message news:<WLadnQcmb9tb5AGiRVn-hg@comcast.com>...
> "Jem Berkes" <jem@users.pc9__org> wrote in message

> Why is this any better than "sanitizer", at
> http://www.impsec.org/email-tools/pr...security.html? That was written
> in perl, is quite portable and is easily integrated to any procmail capable
> Mail Transport Agent?
>
> If your tool has some cool new feature or features, great. If it's
> considerably faster or lighter weight, also great. But otherwise, why should
> we use yet another of the dozens of mail-filter programs published, and
> worse yet work with a beta release that hasn't been put through the
> trial-by-fire of popular usage?

Nico;

You've been here, what, maybe 2 weeks??? So let me clue you...

Jem's software was a response to a complaint of mine some three, maybe
four years ago, when this list was discussing the probability that
mail worms were the most significant threat the Internet would face in
the next few years.

As it turns out, we were right. Moreover, as it turns out, Jem's
software it the simplest solution to that problem which has ever
surfaced. That would include Vipul's Razor, Spam Assassin, and even
Bayesian Filters. "Why?" would be your next question. I would reply
that the problem remains Microsofts unwillingness to just fix their
*STUPID* software. HENCE, rename any threatening attachments and
you've solved 99.8 percent of the problem.

So... kindly get a clue and don't prove yourself a moron on this list
BEFORE you have tenure.

Thanks.

-m-

"Michael Erskine" <osiris@deltaville.net> wrote in message
news:e59f93b2.0310281540.712fb9bd@posting.google.c om...
> "Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message
news:<WLadnQcmb9tb5AGiRVn-hg@comcast.com>...
> > "Jem Berkes" <jem@users.pc9__org> wrote in message
>
> > Why is this any better than "sanitizer", at
> > http://www.impsec.org/email-tools/pr...security.html? That was
written
> > in perl, is quite portable and is easily integrated to any procmail
capable
> > Mail Transport Agent?
> >
> > If your tool has some cool new feature or features, great. If it's
> > considerably faster or lighter weight, also great. But otherwise, why
should
> > we use yet another of the dozens of mail-filter programs published, and
> > worse yet work with a beta release that hasn't been put through the
> > trial-by-fire of popular usage?
>
> Nico;
>
> You've been here, what, maybe 2 weeks??? So let me clue you...

Heh. Heh. Bwa-ha-ha-ha! I'm sorry, but if you check old logs from various
groups, you'll see that my presence on email lists as a spamfighter dates
right back to the first Canter&Siegel Green card spam, and my first
professional virus clean-up job was the Morris Worm (which has its 15 year
anniversary this Sunday!) I'm one of the more active posters on
comp.os.linux.security.

Or perhaps you meant comp.security.unix? Admittedly, I haven't been hanging
out there: too general of material.

> Jem's software was a response to a complaint of mine some three, maybe
> four years ago, when this list was discussing the probability that
> mail worms were the most significant threat the Internet would face in
> the next few years.

Cool. I hadn't heard of it in my spam adventures, and assumed it was
therefore a new and rather untested product. I'm pleased to be wrong and
that it's actually been used under load.

> As it turns out, we were right. Moreover, as it turns out, Jem's
> software it the simplest solution to that problem which has ever
> surfaced. That would include Vipul's Razor, Spam Assassin, and even
> Bayesian Filters. "Why?" would be your next question. I would reply
> that the problem remains Microsofts unwillingness to just fix their
> *STUPID* software. HENCE, rename any threatening attachments and
> you've solved 99.8 percent of the problem.

I agree this is a problem. Unfortunately, I've run into the shrieking when
users get their attachments disabled or reformatted correctly. Telling your
department secretary^H^H^H administrator that he can't easily receive and
read American Airlines ticket confirmations without difficulty because they
misuse attachments so badly is a potential source of workplace strife. And
telling them they can't read the blinking "ms-tnef" attachments the calendar
server insists on sending is even worse.

Been there, done that, have the scars.

> So... kindly get a clue and don't prove yourself a moron on this list
> BEFORE you have tenure.

You first, junior.

"Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message
>
> You first, junior.

O'tay...



http://groups.google.com/groups?hl=e...linux.security

Work on that a while.

-m-

> I agree this is a problem. Unfortunately, I've run into the shrieking
> when users get their attachments disabled or reformatted correctly.
> Telling your department secretary^H^H^H administrator that he can't
> easily receive and read American Airlines ticket confirmations without
> difficulty because they misuse attachments so badly is a potential
> source of workplace strife. And telling them they can't read the
> blinking "ms-tnef" attachments the calendar server insists on sending
> is even worse.

This type of filtering definitely isn't for everyone. I still recommend a
full-fledged virus scanner if you have the resources for it. The
"shortcuts" I'm using in my software (looking at file extension) is
obviously not foolproof, and will cause problems if endusers are mailing
around executable attachments.

Filtering just based on filename does achieve a high accuracy with very
little resource impact. It's a trade-off, of course. Another way to look at
it: I'm trying to handle all the possible valid MIME headers _and_ a huge
number of improperly formatted headers too. Given the near-infinite cases,
it's impossible to achieve 100% accuracy.

For instance, I currently have in my database one email whose attachment is
not recognized by filename. Although the filename 'scan' failed, the
message is still caught by the executable data signature in the encoded
body. In RC2 I will correct for this particular type of improper MIME.

Then again, I just obtained another sample that looks like an email worm
but which is not currently detected by ANY commercial virus scanner -- I've
submitted the sample to McAfee. Goes to show that the major commercial
virus scanners can't catch everything either.

--
Jem Berkes
http://www.sysdesign.ca/

"Jem Berkes" <jem@users.pc9__org> wrote in message
news:Xns9423F316ADF89jbuserspc9org@205.200.16.73.. .

> For instance, I currently have in my database one email whose attachment
is
> not recognized by filename. Although the filename 'scan' failed, the
> message is still caught by the executable data signature in the encoded
> body. In RC2 I will correct for this particular type of improper MIME.
>
> Then again, I just obtained another sample that looks like an email worm
> but which is not currently detected by ANY commercial virus scanner --
I've
> submitted the sample to McAfee. Goes to show that the major commercial
> virus scanners can't catch everything either.

Excellent. Nice to see that you're maintaining it and working to keep it
up-to-date.

"Michael Erskine" <osiris@deltaville.net> wrote in message
news:e59f93b2.0310291650.644c5ac4@posting.google.c om...
> "Nico Kadel-Garcia" <nkadel@comcast.net> wrote in message
> >
> > You first, junior.
>
> O'tay...
>
>
>
>
http://groups.google.com/groups?hl=e...linux.security
>
> Work on that a while.
>
> -m-

Rewritten to show your oldest results, I get:


http://groups.google.com/groups?as_e...ng=d&lr=&hl=en

Checking my oldest results also dates back to 1991, with my name before I
married (Nico Garcia-Otero). Shall we dig back into the old Morris Worm
history, or the archives of the very first mailing list ever (Bandykin)?