[8961] in bugtraq
Re: Anonymous Qmail Denial of Service
daemon@ATHENA.MIT.EDU (D. J. Bernstein)
Wed Jan 6 13:09:25 1999
Date: Tue, 5 Jan 1999 22:41:44 -0000
Reply-To: "D. J. Bernstein" <djb@CR.YP.TO>
From: "D. J. Bernstein" <djb@CR.YP.TO>
To: BUGTRAQ@NETSPACE.ORG
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 wietse@porcupine.org. A few basic methods:
* Send lots of messages to mailinglistmanager@whatever with a return
path and From line of wietse@porcupine.org. Automated responses
will go back to wietse@porcupine.org.
* Send lots of messages to legitimateuser@whatever with a return
path of wietse@porcupine.org. After the legitimateuser mailbox
fills up, messages will bounce to wietse@porcupine.org, 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 wietse@porcupine.org.
* Subscribe wietse@porcupine.org 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
