[8752] in bugtraq
Claimed Postfix Vulnerabilities
daemon@ATHENA.MIT.EDU (Wietse Venema)
Mon Dec 21 14:56:32 1998
Date: Mon, 21 Dec 1998 13:59:44 -0500
Reply-To: Bugtraq List <BUGTRAQ@NETSPACE.ORG>
From: Wietse Venema <wietse@PORCUPINE.ORG>
To: BUGTRAQ@NETSPACE.ORG
In the first week after its public release, people have subjected
the Postfix software to a high level of scrutiny. I will respond
to the claims that have been made sofar. In my opinion, no-one has
brought forward a vulnerability worth mentioning.
First I'd like to emphasize that the primary objective of Postfix
was to protect the local system. With today's protocols that lack
any form of strong authentication, I make no promise that Postfix
can be made immune against DNS spoofing, IP address spoofing, or
SMTP sender address spoofing.
Secondly, all topics of controversy are the result of deliberate
design decisions, not accidental properties of the implementation.
I suppose that one man's bug is another man's feature.
The remainder of this message addresses specific claims.
Wietse
By default, Postfix relays mail from sites within the local domain
or subnetwork. In addition, the system administrator can set up
access controls on the basis of client host names/addresses, and
on names or mail addresses that are exchanged via SMTP commands.
1 - Claim: Postfix relay restrictions can be bypassed with forged
PTR records.
Response: in my opinion, the current measures raise the bar to
a sufficient level.
Postfix uses a world-readable/writable/executable, sticky maildrop
queue directory for locally-posted mail. Postfix uses world write
permission to avoid the need for set-uid/gid posting software.
The Postfix queue directory is world-readable because queue file
names are not strong secrets.
2 - Claim: local users can slow down Postfix by flooding the maildrop
directory.
Response: local users have lots of means to slow down the entire
machine, not just Postfix. Standard UNIX accounting facilities
can be used to expose the culprit. Once the sysadmin has found
and shot him/her/it, Postfix will catch up.
3 - Claim: local users can see Postfix maildrop queue files.
Response: there is no loss of privacy. Local users cannot access
the content of other user's Postfix maildrop queue files.
Postfix has a "mailq" command that gives away more information.
4 - Claim: a local user can make hard links to Postfix maildrop
queue files and thus prevent mail from being delivered.
Response: the mail will be delivered. When a queue file has
more than one hard link, Postfix deletes the hard link, and
logs a warning. When the hard link count reaches 1, Postfix
delivers the mail. See also claim #2. Standard UNIX accounting
facilities can be used to expose the culprit.
5 - Claim: a local user can make a hard link to a mode 0700 file
outside the maildrop directory and have that delivered as mail.
Response: the file will not be delivered. See also claims #4
and #2. Postfix deletes the hard link in the maildrop queue
directory, and logs a warning. In addition to this, Postfix
queue files have a very specific file format that is produced
by no other software, and Postfix insists that queue file
records be written in a very specific order. Postfix deletes
queue files that do not satisfy all requirements. Standard
UNIX accounting facilities can be used to expose the culprit.
6 - Claim: a local user can chown files and impersonate another
user.
Response: Postfix uses the queue file numerical uid for logging
purposes only. Standard UNIX accounting facilities can be used
to expose the real culprit. The unauthenticated SMTP protocol
provides much more effective means for impersonation.
7 - Claim: world-writable directories are the cause of more
vulnerabilities than set-uid programs.
Response: both world-writable directories and set-uid/gid
programs require a great deal of care. This is a matter of
taste, not of dispute.
