ietf-mxcomp
[Top] [All Lists]

Re: extensibility as an attack vector

2004-06-23 16:44:05

On Wed, 2004-06-23 at 14:32, Hadmut Danisch wrote:
On Wed, Jun 23, 2004 at 12:46:02PM -0500, Eric A. Hall wrote:

What is the possibility that an attacker could list a (SID|SPF) record
with references to ~thousands of domains, forcing my SMTP server to spend
large amounts of time and/or processing power validating the junk data?
What other similar kinds of attacks are enabled by infinite extensibility?

There is also still the argument that 513-byte records affect a DDoS
attack against my domain.

The more I think about this, the less I think that extensibility is a good
idea in general.

No. This is not a problem of extensibility. 

This is an attack outside the threat model. 
All these caller authorization methods are designed against 
an attacker who does not want to reveal his identity (=domain).

If the attack simply provides the wrong name, it may take a prolonged
period to discover this falsehood.  The hostile intent is to disable the
channel checks for MARID.  If the lie is perpetrated many times to
different destinations, then the hapless name server would be expected
to become erratic.  (MARID=DDoS)

An attacker who attacks you while not hiding his own domain is 
a different kind of attack. Such an attacker could also simply
allow mail from 0.0.0.0/0, thus authorizing all IP addresses in 
order to allow spam.

Nothing so brazen is needed. Real open lists provide the same avenue for
committing fraud.  Without requiring an absolute acceptance of
accountability, as perhaps with EHLO, the system remains prone.  This
absolute is not possible if based upon other identities.  It must
reference the domain currently sending mail.

This has already been discussed more than a year ago in ASRG and 
addressed in RMX and other proposals. It is up to you to define
a policy about domains you're willing to accept mail from. 

I doubt there is such a safe area with SPF/CID.

E.g. you could choose to not accept mail from domains authorizing 
more than 50 IP addresses.

If my domain points to AOL as an outside provider and they have this
number, then my mail becomes rejected?  How can such a policy apply
uniformly without millions of exceptions?

Thus the interpreter could reject messages from domains with
such a record with thousands of references without performing
a single query. And you should do it. 

Whatever limit you define, that will become known to the attacker
learning to fly below your radar.

Imagine this attack: An attacker is sending millions of spam with 
his own sender address   @attacker.tld   
His MARID record is generated dynamically with thousand references 
of the type  randomnumber.victim.tld

Thus the victim's DNS server will have to serve billions of queries. 
You need limits.

The standard needs limits. For EHLO checks, it could be just one.

But, if this happens, you know at least the domain the attacks came
from.

How?  If the attacker referenced an open list, there was never any
positive identification.

It is similar to the case where the spammer simply used his 
own domain as a sender address (=does not fake). Fake protection is 
useless against attackers who do not fake.

This was in regard to an attack where even real records offer a means to
obfuscate the identify of the host sending mail.  With perhaps millions
unwilling to close lists due to a loss of an ability to use alternative
access, those wishing to abuse the system are afforded ample means to
hide their identify and evade being categorized. 

You still need blacklisting, but now blacklisting is possible. And you
need whois entries which allow to identify the person responsible for 
the domain.

How does blacklisting become more effective if the identification
remains unknown?  SPF/CID create valid reasons for retaining open
lists.  Their existence doom any scheme that relies upon positive
identification.  Outside the use of the EHLO domain, where can
identification become strict without breaking SMTP?  

-Doug


<Prev in Thread] Current Thread [Next in Thread>