Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSN attacks

From: "Daryl Odnert" <[email-masked]>
Date: Tue, 31 Aug 2004 09:47:52 -0700

Chris Haynes wrote:
> > Normally, only MTAs that are operated by (or trusted by) V for outbound
> > SMTP mail processing would be configured this way.  Therefore, the
attack
> > is only likely to occur if it can be launched from an IP address that
> > normally submits mail from V to P.
>
> I'm very sorry, I just don't understand this point.
> Dues it change in the light of my comments / draft amendments above?

My point is that the vulnerability your are describing presumes the
existence of an MTA (which you've labeled P) with several
assumptions made about the behavior of that MTA.  You need to make it
clear what those assumptions are so that others can fairly assess the
risks.

One of the assumptions you have made is that P is normally willing
to accept a message where the SMTP sender is V and the recipient is R.
Let's assume that V and R are distinct domains.  Nearly every MTAs in
use today has configuration controls to prevent "open relaying".  These
controls limit the IP addresses from which mail will be accepted for
relaying to outside domains.  Most MTAs will perform the open relaying
check immediately after the RCPT command or immediately after the end
of the message DATA is received.  The message is rejected during the
SMTP conversation if the combination of (client IP address, sender
address, recipient address) is unacceptable to the MTA.

Assuming the MTA at P is not configured as an open relay and that IP
address spoofing is not involved, the only way that P will accept a
message with a sender address in V and recipient in domain R is if
the SMTP client is one that P believes is "owned by" V - that is, it
normally sends mail to P on behalf of V.

To put it in simple terms, you cannot launch this type of attack
against V using P using unless one of the following is true:

(1) P is an open relay.

(2) The attack messages are sent to P from an IP address that
normally sends mail for domain V.

(3) IP address spoofing is used to make it look like the attack
message is coming from an IP address that normally sends mail for
domain V.

Do you agree?  If so, then I think this is important to mention
because it significantly reduces the risk level associated with
the vulnerability you're writing about; one cannot easily launch
this type of attack from anywhere on the Internet.

Regards,
Daryl Odnert
Tumbleweed Communications
Redwood City, California

---

From: <[email-masked]>
Date: Tue, 31 Aug 2004 12:54:28 -0400

>this type of attack from anywhere on the Internet.

I disagree because "anywhere on the internet" has to include the thousands of trojaned workstations
(and even servers) that are in the wild.

Terry Fielder
Manager Software Development and Deployment
Great Gulf Homes / Ashton Woods Homes
[email-masked]
Fax: (416) 441-9085

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Daryl
Odnert
Sent: Tuesday, August 31, 2004 12:48 PM
To: 'Chris Haynes'; IETF MARID WG
Subject: RE: TECH-OMISSION: Security vulnerability - Malicious DSNattacks

Chris Haynes wrote:
> > SMTP mail processing would be configured this way.  Therefore, the attack

Regards,
Daryl Odnert

---

From: "Carl S. Gutekunst" <[email-masked]>
Date: Tue, 31 Aug 2004 11:28:39 -0700

> message is coming from an IP address that normally sends mail for
(4) The attack messages are sent to P from an IP address that P 
considers to be part of its own management domain, and it puts no 
restrictions on either the MailFrom or the From header field from such 
IP addresses.

I believe (4) applies to the overwhelming majority of ISP's submission 
hosts, including all three ISPs that I use regularly, and every hotel, 
airport, and public WiFi I've used in the past year.

<csg>