qmail-DoS-anonymous.txt

`Date: Tue, 5 Jan 1999 22:41:44 -0000  
From: D. J. Bernstein <[email protected]>  
To: [email protected]  
Subject: Re: Anonymous Qmail Denial of Service  
  
News flash: There are dozens of denial-of-service attacks on every MTA.  
  
Example: Any Internet user can create a continuing torrent of mail from  
random Internet addresses to [email protected]. A few basic methods:  
  
* Send lots of messages to mailinglistmanager@whatever with a return  
path and From line of [email protected]. Automated responses  
will go back to [email protected].  
  
* Send lots of messages to legitimateuser@whatever with a return  
path of [email protected]. After the legitimateuser mailbox  
fills up, messages will bounce to [email protected], in some  
cases with a delay.  
  
* Relay lots of messages through MTAs with spam-friendly defaults.  
For example, postfix allows relaying from the local network. If a  
postfix system is dialing into an ISP as (say) 18.25.0.221, and  
you're dialing in as (say) 18.25.0.37, then you can queue messages  
on that system for [email protected].  
  
* Subscribe [email protected] to an automated mailing list. The  
majordomo 1.* cookie mechanism doesn't stop this attack; it isn't  
cryptographically secure. (Several students in my cryptography  
class two years ago were able to break it, under time pressure, as  
an extra-credit problem on the midterm.)  
  
Thousands of these attacks, producing millions of messages, can be  
carried out in a matter of minutes. The porcupine.org (postfix) SMTP  
server and mail queue will be flooded, making it practically impossible  
for legitimate mail to get through. You can easily remain anonymous, for  
example by abusing the student Internet terminals at MIT.  
  
As another example, here's a denial-of-service attack on postfix:  
  
Connect to the SMTP server at 127.0.0.1 and inject a mail message.  
Repeat ad nauseam.  
  
Most MTAs are able to log the user responsible (by contacting port 113  
and dropping unidentified connections); postfix doesn't even try.  
  
  
Okay, okay, I admit that this isn't news. Here's what I said in the  
qmail documentation, starting with the first release three years ago:  
  
There are lots of interesting remote denial-of-service attacks on any  
mail system. A long-term solution is to insist on prepayment for  
unauthorized resource use. The tricky technical problem is to make  
the prepayment enforcement mechanism cheaper than the expected cost  
of the attacks.  
  
Denial-of-service attacks have always been excluded from the qmail  
security guarantee (http://pobox.com/~djb/qmail/guarantee.html). They  
are present in every MTA, widely documented, and very difficult to fix.  
  
  
On the bright side, mailers are _not_ permitted to discard messages for  
frivolous reasons such as full disks. They have to report the problem to  
the sender, so that the sender can keep the message and try again later.  
  
This isn't just common sense. It's also in RFC 1123, Host Requirements,  
section 5.3.3, Reliable Mail Receipt:  
  
When the receiver-SMTP accepts a piece of mail (by sending a "250 OK"  
message in response to DATA), it is accepting responsibility for  
delivering or relaying the message. It must take this responsibility  
seriously, i.e., it MUST NOT lose the message for frivolous reasons,  
e.g., because the host later crashes or because of a predictable  
resource shortage.  
  
I'm keeping a list of mail clients that do not handle failures properly;  
see http://pobox.com/~djb/docs/maildisasters/queueloss.html. Please let  
me know if you have any additions to the list.  
  
  
This thread began when Venema claimed that it was impossible to track a  
user who fills up qmail's queue by repeatedly running and killing  
qmail-queue.  
  
Venema's claim is false. Every inode created this way requires a new  
qmail-queue process. The process is visible in the standard UNIX process  
list while it is running, and with an X entry in the standard UNIX acct  
mechanism after it has been killed; either way, the user is identified.  
X entries are sometimes created by legitimate users, but not in the  
volume that would be required to fill up the mail queue. Occasional Xs  
are not sufficient to carry out this attack, since each inode is  
automatically removed by qmail-clean after an appropriate delay.  
  
Venema further claims that ``a set-uid posting program cannot guarantee  
user identification.'' That claim is false. The user id is provided by  
the standard UNIX getuid() system call.  
  
See http://pobox.com/~djb/qmail/venema.html for comments on Venema's  
previous denial-of-service accusations.  
  
  
For the record, nothing here should be interpreted as advocating the  
setuid/setgid concept. As I wrote in the qmail documentation in 1995:  
  
A setuid program must operate in a very dangerous environment: a user  
is under complete control of its fds, args, environ, cwd, tty, rlimits,  
timers, signals, and more. Even worse, the list of controlled items  
varies from one vendor's UNIX to the next, so it is very difficult to  
write portable code that cleans up everything.  
  
Of the six most recent sendmail security holes, three worked only  
because the entire sendmail system is setuid.  
  
But my conclusion was merely to be very, very careful: ``Do as little as  
possible in setuid programs.'' The alternatives, such as world-writable  
directories, are horrendous. We'll be stuck with setuid and setgid until  
UNIX develops a simple, portable, reliable, secure IPC mechanism.  
  
---Dan  
  
`