Date:	Mon, 21 Dec 1998 13:59:44 -0500
From:	Wietse Venema <wietse@PORCUPINE.ORG>
Subject:      Claimed Postfix Vulnerabilities
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.