Re: SUMMARY Security Info (root broken)

[lm () melb cpr itg telecom com au (Luke Mewburn)]

> Preventative measures include ensuring that all accounts have a mailbox,
> even an empty one.  Set the global /usr/lib/Mailrc file to include
> the line 'set keep', and build all other mail user agents to leave
> an empty mailbox, instead of deleting it when one deletes all mail.

> When adding a user, create a zero-length mailbox for that user.
> [ ... ]

> And most important, REPLACE OR FIX BINMAIL.  The current patch offered
> by Sun apparantly does NOT fix the problem, only alters it.  Using
> something built from mail.local.c from the NetBSD distribution is a good
> alternative.
> [ ... ]

> One of the respondents (Chuck Cranor - chuck () maria wustl edu) sent such
> a replacement he has used, it is included in this summary.  BE WARY OF
> ALL PRIVILEGED PROGRAMS THAT CREATE TEMPORARY FILES IN /tmp.  Too often
> these programs also have a race condition, and one can predict the name
> of the temp file the program will use, and thus exploit this.  This is
> not helped by having all the mailboxes in place, since this works in
> tmp instead of the mail spool.  If one has source, at lease make sure
> that the temp files are created and opened via the mkstemp() call, not
> mktemp() followed by an open.  Check via lstat and fstat to ensure the
> file one opens is the one that one THINKS one is opening.  The program
> appended adds another wrinkle - using chroot() and fchroot() to limit
> the scope of where links can point to if a link is somehow slipped under
> the the program via winning a race.  As long as checking the file to be
> opened and the open are not atomic, potential for this problem exists
> with privileged programs.

I think that Pat has highlighted here the problem with a lot of
packages that use a setuid root process to create a file in a
restricted directory (e.g, a 775 root.mail /var/spool/mail.)

I've looked at the 4.4BSD-lite (NetBSD uses this) mail.local.c and at
first, thought there was a potential race condition in the code
where it does an lstat check then an open, thinking there was a race
condition. Checking the man page for open() however, revealed the
following tidbits:
        If path is a symbolic link and O_CREAT and O_EXCL are set,
         the link is not followed.
(From Solaris 2.3, and the NetBSD-current man page says something
similar.)

So, it seems that a standard (POSIX?) has explicitly given us a method
to atomically create a file if it doesn't exist, whilst at the same
time not getting fooled by a dangling symlink (which is a common way
to exploit setuid race conditions, correct?)

Now, I don't know if this helps people on systems where this behaviour
doesn't exist (I'm not sure if Sunos 4 supports this, for example.)

It's the creating of the new file by a priviliged process that
is the critical region that so often gets spoofed by a race
condition.  I have some (simple - thus easy to follow and assure
is correct - I hope :) code at home that I was working on which should
work without a race condition (using the atomic link()), so I'll
post it tomorrow to get disected by those with more experience than
I. If it does work the way I expect it to, I feel that a simpler,
more effective, mail.local could be implemented that didn't rely upon
the O_CREAT | O_EXCL feature of newer systems I described above...


Luke.

[ Sorry if this has been discussed already; I've only recently joined
  bugtraq.]

-- 
Luke Mewburn, <lm () cpr itg telecom com au>
`Think of it as Evolution in Action.' - "Oath of Fealty", Niven & Pournelle