Wonder if I'll be the first to forward this here... (I know I won't be the
last..)
--Adam
----- Original Message -----
From: Wietse Venema <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Monday, January 04, 1999 12:04 AM
Subject: Anonymous Qmail Denial of Service
:In recent postings, Daniel Bernstein expands on the insecurity of
:the Postfix world-writable directory for local mail submission.
:Of all the attacks possible with such a scheme, one attack would
:result in mail not being delivered. That is of course unacceptable.
:
:After my request for input from the Bugtraq membership I received
:much useful feedback. Many suggestions were made for implementing
:a private rendez-vous between unrelated, untrusting processes. I
:will try write up a summary of the responses.
:
:I am grateful for all suggestions for improvements that were made,
:in particular for one suggestion made by Daniel Bernstein himself,
:in this same forum:
:
: Why doesn't [Postfix] use a protected queue, and a setuid
: program to add mail to the queue with guaranteed user
: identification?
:
:Postfix uses a set-gid program and a mode 0770 submission directory,
:and it does so for a very good reason. Why doesn't Postfix use a
:set-uid program, as suggested? The reason is that contrary to Daniel
:Bernsteins's claim, a set-uid posting program cannot guarantee user
:identification. I will illustrate this misconception with an example.
:
:qmail uses a set-uid posting program, called qmail-queue. When
:this program is invoked, it opens a queue file somewhere below
:/var/qmail/queue. For example:
:
: -rw-r--r-- 1 qmailq qmail 0 Dec 31 17:02 queue/mess/21/674956
:
:What happens when the qmail-queue process is signaled with, say,
:SIGKILL? The file will stay in the queue. That's a zero-length
:file, owned by qmail, without any user identification whatsoever.
:
:Each time a user does something like:
:
: % /var/qmail/bin/qmail-queue
: ^Z
: Suspended
: % kill -9 %1
: [1] Killed /var/qmail/bin/qmail-queue
: %
:
:There will be one more zero-length file, owned by qmail, without
:any user identification whatsoever. It is an exercise for the
:reader to write a small program that automates the process:
:
: fork a child
: child: execute /var/qmail/bin/qmail-queue
: parent: wait briefly and SIGKILL the child
:
:When this sequence is executed a sufficient number of times, the
:queue file system runs out of available resources. No-one can send
:mail. No-one can receive mail. And no-one can be held responsible.
:
:I fully agree with Daniel Bernstein that every mail system, be it
:Postfix or qmail or anything else, should be able to add mail to
:the queue with guaranteed user identification. I am grateful for
:reminding me of this very important and very desirable property.
:
:The lack of user identification as described above was verified on
:BSD/OS 2.1, BSD/OS 3.1, and FreeBSD 2.1.1. It is reasonable to
:expect that the same behavior exists on other BSD systems/versions.
:
:When the same tests are run on Solaris 2.6, RedHat 5.0, and on
:SunOS 4.1.3_U1, the only difference is in the queue file group
:ownership attributes:
:
: -rw-r--r-- 1 qmailq users 0 Dec 31 18:10 queue/mess/1/418325
:
:What can be done about this lack of accountability? On non-BSD
:systems, the hole can be worked around by placing every user in a
:different group, so that a malicious user can be recognized by the
:queue file group ownership. That will not close the hole on BSD
:systems, however. For this reason, the preferable solution is to
:close the hole by changing qmail. For this I suggest the use of a
:set-gid posting program, similar to the one that is used in Postfix.
:
: Wietse
:
