Date:	Tue, 22 Dec 1998 00:20:21 -0000
From:	"D. J. Bernstein" <djb@CR.YP.TO>
Subject:      Why you should avoid world-writable directories
To:	BUGTRAQ@NETSPACE.ORG

The IBM Secure Mailer, also known as Postfix, provides a mode-1777
directory for users to drop off queue files. All incoming and outgoing
messages pass through this mechanism.

This deliberate design decision leads to four obvious security holes, of
varying levels of applicability and severity, as described here. The
nastiest one is #2: selective anonymous message destruction.


1. Anonymous snooping

SECURITY HOLE: Any local user can stat() files in the IBM Secure Mailer
drop directory.

IMPACT: Any local user can anonymously inspect the uids and sizes of new
messages. It doesn't matter how well the system administrator has
protected his process list, mail logs, and message transport mechanisms;
private information is freely available in the IBM Secure Mailer queue.

One might naively respond that queued messages are visible for only a
moment. However, the attacker can drastically slow down the IBM Secure
Mailer (for example, by creating thousands of temporary files in the
drop directory) to give himself ample time to look for queued messages.

Making the drop directory unreadable does not stop this attack, or even
slow it down perceptibly. Queue file names are easy to predict.


2. Anonymous message destruction

SECURITY HOLE: Any local user can make hard links to files in the IBM
Secure Mailer drop directory.

IMPACT: Under the IBM Secure Mailer, any local user can anonymously
eliminate selected messages from the mail queue. It is impossible to
identify the culprit after the fact.

There are several ways to carry out this attack. The attacker can, for
example, create a temporary directory under a weird name inside the drop
directory, and link the victim's message file to a new name inside the
temporary directory. The IBM Secure Mailer will then remove the original
name because it has too many links. The attacker can then remove the new
link and the temporary directory. It is easy to avoid detection.

Wietse Venema, author of the IBM Secure Mailer, claims that the mail
will be delivered. That is false. I invite other security experts to
verify and publicly confirm that the IBM Secure Mailer allows message
destruction by local users.

Venema also claims that standard UNIX accounting facilities can be used
to expose the culprit. That is false. UNIX accounting keeps track of
which users were running programs and for how long; it does not reveal
what those programs were doing.


3. Anonymous mailbombing

SECURITY HOLE: On (uncommon but still extant) UNIX variants that allow
file giveaways, any local user can create files in the IBM Secure Mailer
drop directory owned by another user.

IMPACT: On UNIX variants that allow file giveaways, any local user can
use the IBM Secure Mailer to send mail that is logged as another user.
This dodges mail accounting; it can be used to send anonymous mailbombs.
It is impossible to identify the culprit after the fact.

Other MTAs are careful to record the source of each local message. They
also attempt to record the source of remote messages, specifically the
IP address and optional extra information supplied by the remote host;
there are still some security holes here that permit anonymous mail (and
mail destruction!), but all of those flaws will eventually be fixed by
cryptographic techniques.


4. File theft

SECURITY HOLE: Any local user can make hard links into the IBM Secure
Mailer drop directory from files visible elsewhere in the filesystem.

IMPACT: An attacker can force the IBM Secure Mailer to send a victim's
file as a mail message, under the following conditions: the file has
mode 700; it is in a world-readable directory on the right filesystem;
it happens to have the right structure for an outgoing mail message; and
it is removed by the victim.

Venema claims that the file will not be delivered. That is false. There
are, as above, several ways for the attacker to put the victim's file
into the IBM Secure Mailer drop directory with the correct name and link
count after the file is removed by the victim.

Venema also responds that queue files have ``a very specific file format
that is produced by no other software.'' No evidence is presented for
this bold claim. There are obvious examples of files whose contents are
partly private, making theft a serious problem, and partly under control
of an attacker; what happens if a UNIX mbox is fed through the standard
UNIX split utility, changed to mode 700 for transport, and then removed?

I don't plan to engage in further evaluation of the applicability of
this security hole. I consider it unacceptable that some file formats
can be mailed without the owner's consent.


5. Technical notes

The standard solution to linking problems in the security community is
to avoid world-writable directories. For example, if a user puts
temporary files into $HOME/tmp, and there are no world-writable
directories on the $HOME filesystem, then there's no place for an
attacker to put an anonymous hard link. (I think that link() should be
prohibited for anyone except the file owner. Unfortunately, that's not
how UNIX works today.)

Why doesn't the IBM Secure Mailer use a protected queue, and a setuid
program to add mail to the queue with guaranteed user identification?
The documentation claims that this is a security feature! ``No Postfix
program is set-uid,'' it says. ``Introducing the concept was the biggest
mistake made in UNIX history. Set-uid (and its weaker cousin, set-gid)
causes more trouble than it is worth.''

Certainly setuid programs require a great deal of care. They've been
involved in many security disasters, though far fewer than (for example)
world-writable directories. The security community would love to see
another portable IPC mechanism offering guaranteed user identification.
(I suggest that kernels add a getpeeruid() system call, showing the real
uid that called connect(), for UNIX-domain sockets and for loopback TCP
sockets.) However, while we're waiting, we need a few setuid programs.


6. Historical notes

All of the problems described here are obvious from a glance at the IBM
Secure Mailer documentation. Apparently I was the first to point them
out (privately on Thursday, and then publicly on Sunday, in a discussion
of basic security design), but I don't claim any credit for this.

Venema's immediate reaction was outright denial. ``Bernstein is wrong on
all points,'' he said in a public statement in response to a summary of
my comments. ``Bogus. ... Bogus. ... Bogus. ... Bogus.'' Venema
continued by giving an example of how an incompetent intruder might fail
to destroy a file.

Venema then sent a message titled ``Claimed Postfix Vulnerabilities'' to
bugtraq. ``In my opinion, no-one has brought forward a vulnerability
worth mentioning,'' he said. He began by talking about some of the
spam-friendly defaults in the IBM Secure Mailer, and then continued with
a horrendously inaccurate summary of the world-writability problems.

I have one question for Venema: did he honestly believe at that point
that there was no security hole? In any case, he owes an apology to me,
and to the users of the IBM Secure Mailer.


---Dan