[8919] in bugtraq
Anonymous Qmail Denial of Service
daemon@ATHENA.MIT.EDU (Wietse Venema)
Mon Jan 4 02:32:42 1999
Date: Mon, 4 Jan 1999 00:04:09 -0500
Reply-To: Wietse Venema <wietse@PORCUPINE.ORG>
From: Wietse Venema <wietse@PORCUPINE.ORG>
To: BUGTRAQ@NETSPACE.ORG
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
