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?
These attack scenarios have been raised in the past. Seen
from the point of view of "don't spammers want their mail to
get through?" they seem unlikely, but if we counter "but
spammers may want to attack the integrity of the entire
system as a whole" they make more sense.
In fact, your attack scenario can be constructed independent
of extensibility considerations. The moment you introduce a
new behaviour (a MARID dns lookup) you are able to attack it
(a slow SERVFAIL will consume resources). Extensibility
amplifies the attack in degree but not in kind.
We are moving from an "assumed innocent unless proven
guilty" model of email to an "asumed guilty unless proven
innocent" model.
I see this as a simple matter of hygiene in the big city.
If the crazy homeless guy on the street offers me a
bloodstained driver's license, I won't even get as far as
looking at its expiration date; I won't even take it for
fear of disease.
In the same way, the best defense against the attacks you
suggest is to perform the reputation lookup *before* the
authentication lookup.
If the reputation lookup says "bad guy" then the
authentication lookup is moot.
If the reputation lookup says "good guy" then you have
reason to believe the query won't crash your system.
If the reputation lookup says "no reputation, but
accredited" you can provisionally assume "good guy".
If the reputation lookup says "unknown and unaccredited",
If you are being very cautious, you may wish to greylist
and return 4xx without doing the auth lookup at all. A
distributed reputation system should obtain information
fast enough to be useful the next time the query happens.
If you are being less cautious, you can do the auth lookup
anyway, and if it fails to resolve within a reasonable
amount of time, you can abort the lookups and feed a
grumpy opinion into your reputation service. The next
time the attack occurs, you'll know not to do the auth
query. Introduce noise into subsequent iterations
according to game theory to create opportunities for
forgiveness.
Some MTA admins I know are looking at the OS fingerprint of
the incoming packets and rejecting any mail that comes from
a Windows OS. This blocks a lot of viruses at the cost of
cutting out legitimate Windows MTAs. I mention this as an
anecdote only.