Bugtraq mailing list archives
Re: Anonymous Qmail Denial of Service
From: wietse () PORCUPINE ORG (Wietse Venema)
Date: Sun, 10 Jan 1999 17:35:36 -0500
Bernstein's posting contains inaccuracies. Rather than boring the reader I will just address a few. If there is sufficient demand I will make the full list available for those who care.
* The world-writable drop directory was made unreadable. The [Postfix] author called this a ``solution'' and claimed that inode numbers offer 15 bits of randomness. In fact, on almost all UNIX systems today, inode numbers are trivially predictable. This is security through obscurity.
The claim that the non-readable maildrop was offered as a ``solution'' is inaccurate. The non-readable maildrop was offered as a "short-term, interim solution", while a "permanent solution is under development". The announcement is likely to be still on-line. The USENET news Message ID is <75r5q7$a3h$1 () spike porcupine org>. The claim that Postfix file name randomness is based inode numbers is inaccurate. The 15 bits of randomness that I referred to are based the time of day in microseconds, which gives about 15 bits depending on implementation. Now, 15 bits isn't a lot, but this scheme was chosen when queue file names were not meant to be secret. Before I end this post there is one observation that I would like to share with the reader. In December, Daniel Bernstein posted a message to the qmail mailing list with in the subject: "Anonymous postfix denial of service", describing a variety of local attacks with Bernstein accuracy. By way of response I described a local attack in a posting titled "Anonymous qmail denial of service". How memory can fail. Daniel Bernstein denies that he attacked Postfix for being subject to a DoS attack, with the following words: D. J. Bernstein:
Perry E. Metzger writes:You attacked Postfix for being subject to a DoS attack.I pointed out that [Postfix] allowed local users to * anonymously destroy messages accepted by the MTA from other users; * obtain traffic information that some sites consider private; * on some UNIX variants, charge mail to the wrong user; and * under specialized circumstances, steal unreadable files. Which of these are you calling a ``denial-of-service attack,'' Perry?
The claim is in the title, Dan: "Anonymous postfix denial of service". You can find it in your own mailing list archive. Wietse
Current thread:
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service), (continued)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Thamer Al-Herbish (Jan 09)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Len Budney (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Thamer Al-Herbish (Jan 08)
- Re: setuid vs. setgid (was Re: Anonymous Qmail Denial of Service) Kragen Sitaker (Jan 09)
- really silly ff.core exploit for Solaris John McDonald (Jan 07)
- ff.core exploit on Solaris (2.)7 Daniel J. Frasnelli (Jan 08)
- Re: ff.core exploit on Solaris (2.)7 Casper Dik (Jan 15)
- L0pht tmp tool and (mini) Advisory Dr. Mudge (Jan 08)
- ff.core exploit on Solaris (2.)7 Daniel J. Frasnelli (Jan 08)
- Re: Anonymous Qmail Denial of Service Antonomasia (Jan 07)
- Re: Anonymous Qmail Denial of Service D. J. Bernstein (Jan 09)
- Re: Anonymous Qmail Denial of Service Wietse Venema (Jan 10)
- Keeping Solaris up-to-date John RIddoch (Jan 11)
- Keeping any up-to-date? Randolf-Heiko Skerka (Jan 13)
- Re: Keeping any up-to-date? Ciaran Deignan (Jan 15)
- Re: Keeping any up-to-date? Peter May (Jan 15)
- Administrivia Aleph One (Jan 12)
- Tracing by uid u after root does setuid(u) D. J. Bernstein (Jan 12)
- Re: Tracing by uid u after root does setuid(u) Wietse Venema (Jan 13)
- Re: Tracing by uid u after root does setuid(u) Casper Dik (Jan 13)
- Re: Tracing by uid u after root does setuid(u) James Mathiesen (Jan 15)
- Re: Tracing by uid u after root does setuid(u) Gene Spafford (Jan 13)