Re: SUID pop3 / imap4?

[xystrus]

On Fri, Apr 05, 2002 at 12:24:44AM -0500, Sam Roberts wrote:
> > > I believe neither of them should do it. Pop3d is supposed to be
> > > started with root privileges. Installing it setuid requires careful
> > > analysis of possible security implications.
> > 
> > OYE.  I will reiterate:  THERE IS NO DIFFERENCE BETWEEN RUNNING AS ROOT AND
> > SUID.
> 
> Not to sure what you mean by no differences, the uid is different, for
> instance.

Yeah, sorry.  When I make such a statement it comes from this
perspective:  As a system administrator, in most of the environments
in which I've worked in the past, we have generally not allowed users
to log into the mail server, and all access to mail spools (at least
initially) was exclusively via POP3 or IMAP.  In such cases, local
exploits are irrelevant, since the only people who have access to the
machine have root anyway.  Therefore, the only exploits you need to
worry about are remote ones.

In such a case, the attacker is going to attack a running instance of
the program.  In such a case, it does not matter if the program was
SUID root, or if it was kicked off by root; in either case, it is
running with root priviledges, and if compromized will give the
attacker root priviledges.

To address your point about different uid, that's really irrelevant.
While the real uid of this process may not be root, the effective uid
is root, and the attacker could (assuming he compromised the daemon)
easily exec a program which does the equivalent of this:

        setuid(0);
        execl("/usr/bin/bash", "/usr/bin/bash");

Now they have a shell where the UID, SUID, and EUID are all root.
The fact that the original UID was not 0 does not matter one iota.
Yes, there are differences, but at least from the perspective of a
remote exploit, none that matter.

My point was mainly that *any* program that regularly runs as root
needs to undergo careful scrutiny for possible exploit situations.
SUID programs aren't different in this respect; they just are a lot
easier to screw up, and provide an easier exploit path because people
who already have access to the system are much harder to defend
against than those who do not.  This is a good reason not to allow
people to have access to your mail server (or any server for that
matter), unless you absolutely need to.  It eliminates local root
compromise scenarios.

Regardless of whether you choose that path or not, the amount of
scrutiny such programs should undergo should be no more and no less
than those programs which are not SUID but intended to always run as
root.  That is, anywhere the program interacts with users, or the
systems from which they are contacting it,  is a potential attack
point and should be scrutinized very carefully.  The only difference
is that SUID programs have a lot more of those points, if untrusted
users are allowed to log into the system.

Remember too, that not making the program SUID does not eliminate
local exploit opportunities.  You still need to watch out for buffer
overflows, race conditions (such as those with temp files), etc. etc.
Anywhere that the program is not entirely self contained (i.e.
anywhere the code interracts with the environment, the filesystem, the
user, or a remote machine), you must make dilligent effort to ensure
there are no bugs that will crash the program or allow root access
using any of the other myriad of known exploit tecniques.

Xy