----- Original Message -----
From: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>
To: "Hector Santos" <winserver(_dot_)support(_at_)winserver(_dot_)com>
Cc: "Keith Moore" <moore(_at_)cs(_dot_)utk(_dot_)edu>; "IETF-SMTP"
<ietf-smtp(_at_)imc(_dot_)org>
Sent: Tuesday, January 27, 2004 10:57 PM
Subject: Re: CERT Advisory CA-2004-02 Email-borne Viruses
Well, they rely on a combination of human intervention -- in that they
require humans to actually "open" the attachment -- and violations of
the MIME specification by the recipient's MUA.
A big part of the problem is that when the message attachment is
opened, the MUA then executes the content, despite the admonition of
the MIME specifications that
(a) an MUA should not allow the sender of a message to specify what
action the recipient takes to display the attachment (which the sender
effectively does by specifying the filename suffix) and
(b) for types not known to be safe the MOST an MUA should do is to
offer to save the attachment in a file.
Good points Keith. Of course, promiscuous behavior can get one really
dirty :-) Unknown attachments or downloads should not be trusted and open
in any way.
However, I was hoping to reference this not to highlight the end result,
but the distribution process the SORBIG generation of email viruses have
exploited. The new email viruses in this advisory fall in the same
distribution category based on the exploitation of the SMTP functional
specification made famous by SORBIG. This will continue until the real
problem is recognized, addressed and solved at the SMTP level. Developers
will have little to offer as long as the specs relaxed security and
resistance to enforcement is written in stone.
The email-virus distribution logic depends on 3 things:
1) Spoofing other people's valid or partially valid address/domain for
distribution,
2) Spoofing YOUR valid or partially valid address/domain for distribution,
3) Exploiting Anti-Virus Software automated SMTP DSN/error reporting to
expand the distribution.
This is where the focus needs to be as it hits the heart and soul of the
problem we are facing today with the SMTP functional specification.
In short, they work by using valid or partially valid MAIL FROM and valid
RCPT addresses. A group of the mail may or may not make it to the user.
Those systems with AVS software will help the virus distributing by bouncing
the mail back to the return paths.
During SORBIG, depending on the AVS software, one of the problems was the
bounce loops created. So the better AVS software has learned not to include
the attachment in the bounce and/or also learned how to use a proper NULL
Mail From. This round of email-viruses seem to indicate the AVS software
have learned to better handle this. The attachments are not included.
FWIW, Our CBV has addressed a majority of these emails the past few day,
but of course, not all. i.e, a spoofed return path with a invalid user
part but valid domain part. The CBV will catch all of these. However, of
course, it will not catch a complete valid email return path address. In
our case, those getting by the CBV were caught with our AV mail filters.
The result: zero (0) percent penetration.
(Please note, by no means, is the above statement an attempt to convince
you or to solicit endorsement. I am just reporting an observed result of a
CBV helping to curb the current set of email SORBIG-like viruses).
Anyway, starting brand new, throwing out the door a CBV concept, what can
be done to address the above distribution exploitation?
I think with current SMTP specifications, I can only see end-point
solutions, as it is today by depending on AVS software. That is not bad
and I don't think we can completely eliminate end-point mail filtering
technologies. We will always need it or rather the admins and end users
will always need to have it around.
For a SMTP revamp, what can be done at the SMTP level, if any, to minimize
or prevent this distribution exploitation?
Given the information a client provides at the SMTP level, regardless of
how its done, it boils down to validating the sender machine and/or return
path. How can we do this in a highly optimize fashion?
I got several ideas I am working on, but darn it, it keeps coming back to
the functional specs.
How can you work on an idea of validating a return path when the darn specs
allows for it to be non-verifiable? I mean, just consider the IMC.ORG
MAILSERV file request system. It uses an unverifiable
mailserv(_at_)www1(_dot_)imc(_dot_)org(_dot_) How can anyone can any
solution done when the
IETF illustrates by example that the return path is not verifiable? Why
should spammers or anyone for that matter follow 'guidelines' when the IETF
itself can not?
Don't know about you, but there is something wrong with this picture. The
IETF should be the #1 system in the world showing how the protocols should
work as it was intended to work.
--
Hector Santos, Santronics Software, Inc.
http://www.santronics.com