Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
Anonymous Qmail Denial of ServiceWietse Venema (wietsePORCUPINE.ORG)
Mon, 4 Jan 1999 00:04:09 -0500
- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Illuminatus Primus: "Re: Anonymous Qmail Denial of Service"
- Previous message: debian-security-announceLISTS.DEBIAN.ORG: "[SECURITY] New versions of netstd fixes buffer overflows"
- Next in thread: Illuminatus Primus: "Re: 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  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