Re: Solaris /usr/bin/mailx exploit (SPARC)

[woods () weird com (Greg A. Woods)]

[ On Thursday, May 17, 2001 at 12:24:41 (+0200), Casper Dik wrote: ]
> Subject: Re: Solaris /usr/bin/mailx exploit (SPARC) 
>
> Dependign on which loss of features you're willing to accept, it's
> usually not practical to run mail delivery as a non-privileged user;
> currently, we need to do deliver as superuser because of the
> actual delivery runs as the destination user.

The actual delivery need only run as "nobody:mail".  Period.  End of story.

The only trick is that if you're running the queue cleaner (or all of
sendmail, in your case) as root then you have to make sure that you
don't get fooled into not discarding your privileges when running a
setgid binary -- you'll have to first have sendmail do
setgid(nobody);setuid(nobody) before it exec's the LDA.

In any case there's no need to lose any features whatsoever.  Secure
local mail delivery is entirely practical and very achievable.

In reality there's not even any need to run sendmail as root -- the
SMTP daemon should always be started as root, of course, but it can
easily permanently discard all privileges once it's got a socket open
and bound for listening to port-25.

> If you don't run delivery as the targeted user, you can have unrestricted
                                                s/can/must/?
> .forward files  (those are a risk in themselves but tools like procmail
> cannot easily be run under an unprivilegd accoutn on behalf of a user.

If ~/.forward files are supported on any given system then they do have
to be at readable by at least the group 'mail', but they don't have to
be completely unrestricted.  (on *BSD they would have to be, but not
SysV-based system I think, at least not if _POSIX_CHOWN_RESTRICTED isn't
in effect.)

Either way of course it implies that the user's home directory must also
be at least searchable by everyone too.

You can put .forward files into some other place, of course -- they
don't have to be in $HOME....  Doing so even eliminates many problems
when $HOME is on an NFS server (from the mailer's point of view)!

I don't think that allowing group mail to read .forward files is too
much to ask for, and it certainly doesn't mean you have to drop support
for user-controllable e-mail forwarding.  It is after all the difference
between living with the risk of a total system compromise, and not.
(Yes, this thread started with a group-mail compromise, but the reason
that happened was because group-mail configuration wasn't done correctly
in the first place.)

Of course there's still the issue of coding access to these files safely
so that the user can't trick the delivery agent into reading someone
else's mailbox (the only other files that should be private but still
readable by the group 'mail'), but that's much easier to do with just
setgid-mail privs than it is to do with root privileges.

I'll bet you could even easily dig out the old SysV code which supports
putting "Forward to" in the user's mailbox!  That scheme requires no
access to home directories and no new directories, and it can't be
fooled by symlinks (provided you secure /var/mail itself, of course).
Maybe it's even there still in the Solaris mail system -- it wouldn't
surprise me if it were.

> AS things stand today, there doesn't seem to be any reason to continue
> the use of set-gid mail in Solaris, except that some code changes will be
> necessary (or mailboxes will be created mode 660, group pwd->pw_gid

That is true.  If you're going to risk running local delivery as the
superuser then you don't have to use any setgid-mail stuff.  Pick your
poison.

Regardless there should no longer be any reason for enhanced privileges
of any kind on any mail reader program.  (There never was in the first
place, in so far as Solaris is concerned.)

Please don't make excuses for a broken system.  Please fix it!  Please
do your best to avoid potential new problems too, and don't just paper
over them -- learn from history!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods () acm org>     <woods () robohack ca>
Planix, Inc. <woods () planix com>;   Secrets of the Weird <woods () weird com>