Re: patch for the race condition security problem in /bin/mail

[bostic () vangogh cs berkeley edu (Keith Bostic)]

> From: Alain Durand <Alain.Durand () inria fr>
>
> Alerted by the message from 8lgm Mon, 21 Mar 1994 on security problem
> due to a race condition in Sun's /bin/mail, I have a patch to offer
> that solves the problem.

I think I disagree that this patch solves the problem.

Generally, I agree with your analysis and conclusions.  Specifically, I
agree that the real problem is that the mail spool directory is writeable
by ordinary users.  It should be strongly emphasized that if this is the
case, there are multiple attacks that may be made on the system, not just
the local mail delivery agent.  If the mail spool directory is generally
writeable, the system may be be compromised regardless of the local mail
delivery agent.

However, checking both before and after the open only makes the race
harder to hit, not impossible.  The case to consider is if the attacker
deletes the link and then replaces it with a regular file.

If the attacking program replaces the file with a symbolic link after
the lstat, but before the open, and then replaces the symbolic link with
a regular file after the open but before the second lstat, I believe
that the attacker will still avoid the checks you propose.

A better defense (credit to Eric Allman) is that the local delivery
agent does the lstat, the open and the fstat on the returned file
descriptor, and then *compares* the values of the stat calls, most
notably the dev/ino numbers.  This is what the current 4BSD local mail
delivery agent does.  This should be absolutely safe on most systems,
and statistically safe on systems with multiple NFS mounted filesystems.

Three other comments.

First, it's difficult to guarantee that every user has a mailbox as
soon as the account is created, given that various user mail agents
attempt to remove empty mailboxes when users have read all of the mail
they contain.  The correct fix is to make the mail spooling directory
unwriteable by users without appropriate permissions.

Second, mail readers do not require that the mail spooling directory
be writeable.  The only restriction that this imposes is that the reader
cannot remove the file (although it can truncate it to zero length).
As proof of this, 4BSD systems run with the mail spooling directory
owner root, group wheel, mode 755, without any problem.

Finally, the historic local mail delivery agent, binmail, has been 
repeatedly compromised.  A few years back, we replaced it with a small,
backward compatible, carefully reviewed program, named mail.local.  I
doubt that anyone still uses binmail as a mail reader.  It should be
replaced with a more trustworthy local delivery agent.

        Keith Bostic                    +1-508-287-4781
        CSRG
        Department of EECS
        University of California
        Berkeley, CA  94720