RE: Non existing attachments, more info

["Grimes, Roger" <RogerG () GoldKeyresorts com>]

David,

Your second option, although widely implemented by lots of SMTP solutions,
could cause more problems than it solves.  I believe that if the message
isn't RFC-compliant and coded correctly, it should be rejected, period.
Because of how different vendors would implement #2 will allow
maliciously-crafted messages to eventually get around defenses.  Good
security before ease-of-use.  And in some cases, sticking to the RFC's will
lead to better security in the first place.  Example, Microsoft actually had
some bragging rights during the MyParty worm attack last month.  Because
Exchange was RFC-compliant, it rejected outgoing attempts by the worm.  Some
have guessed that the worm's non-RFC coding was designed to sneak around
email-based virus scanners that didn't know how to "re-build" the message
"correctly" and find the worm.

Roger

***************************************************************************
*Roger A. Grimes, VP of IT for GK/PHR Holding Company
*Gold Key Resorts and Professional Hospitality Resources
*email:  rogerg () goldkeyresorts com
*ph: 757-491-2101 x403
*fax:757-491-6550
*932 Laskin Road, Virginia Beach, VA 23451
*Author of Malicious Mobile Code:  Virus Protection for Windows by O'Reilly
*http://www.oreilly.com/catalog/malmobcode/
***************************************************************************


-----Original Message-----
From: David F. Skoll [mailto:dfs () roaringpenguin com]
Sent: Monday, February 18, 2002 10:02 AM
To: Valentijn Sessink
Cc: bugtraq () securityfocus com
Subject: Re: Non existing attachments, more info


On Sat, 16 Feb 2002, Valentijn Sessink wrote:

> A couple of people seemed to think that simply interpreting all <CR>'s
with
> <CRLF>'s should solve the issue, however, that makes things worse, as the
> scanner will now be forced to look "the outlook way".

I initially made my scanner emulate the Outlook bug; now I see it's the
wrong thing to do.

I believe the only sane way to handle these kinds of malformed messages is:

1) Reject any message with suspicious characters in the headers (e.g.,
embedded CR's.)  It's pointless for a server-based scanner to try to
out-think all the different mail user agents out there.

2) Completely rebuild all incoming messages.  The server-based scanner
should parse the MIME as best it can, build its own data structure, and
then rebuild the message using valid MIME.  That way, MUA's are quite likely
to "see" the same message that the scanner did.

I have implemented these procedures in MIMEDefang; see
http://www.roaringpenguin.com/mimedefang/lookout.html for more details.

Regards,

David.