Re: Linux security issues as they pertain to CVS

[Greg A. Woods]

[ On Friday, May 25, 2001 at 10:50:43 (-0400), Larry Jones wrote: ]
> Subject: Re: Linux security issues as they pertain to CVS
>
> The problem is that that question is generally unanswerable.  CVS is a
> big program that, if you follow the general advice for setting up
> pserver, runs as root.  The intent is that it only runs as root long
> enough to authenticate the user and then uses setuid() to run as the
> user for the rest of the time so that all of the actions that you expect
> it to perform will be performed as the user.  However, it is extremely
> difficult to prove that it isn't possible to trick it into doing
> something unexpected while it's running as root, and there are lots of
> known ways to trick it into running code as someone else, even root. 

It is impossible to prove mathematically that such a trick cannot be
performed, at least on any normal unix implementation.

Indeed it is possible on many many systems to trick a formerly
privileged process to return to its privileged status, even if that
program tried to be careful to permanently throw away its privileges.
This means any buffer overflow or printf-format bug that tricks the
process into running code that was not originally part of its binary
image can make CVS run as root again, and of course from there it's
trivial to "own" the whole system (chroot or none, even).

Some of the systems that allow this are buggy.  Others are broken by
design (the system will not let a process permanently discharge its
privileged state).  I have made changes to my NetBSD kernel which I
believe prevent this from ever happening (at the expense of totally
eliminating the ill-designed system calls which allow it in the first
place), but even with those changes I would still not feel safe enough
to run CVS as root from inetd (i.e. as a non-anonymous pserver).

Writing privilged code in Unix is very incredibly difficult to do
correctly (writing privileged code that gets its privileges from being a
setuid binary is of course even harder, but not by a whole lot).  CVS is
turned into privileged code if you start it as root from inetd, whether
it wants to be or not.  CVS was not written anywhere nearly that
carefully, never mind with an eye to being run as root.  Indeed if you
build it normally and try to start it from the command line as root it
will rightfully refuse to run!

Combining this latter fact with the privilege re-enhancing problems and
you're a sitting duck if you run CVS pserver as root.

Worst of all of course is the fact that CVS does not need pserver junk.
It works entirely perfectly with any external remote job execution tool.
In that form it is devoid of all responsibilities w.r.t. authentication,
authorisation, integrity and privacy.  The CVS administrator is free to
choose any external RJE tool that meets their security requirements in
combination with the needs of their clients (eg. rsh, ssh, stunnel, a
VPN+rsh, etc.).  Let the security tools do their job and let them take
responsibility for *all* security issues!

-- 
                                                        Greg A. Woods

+1 416 218-0098      VE3TCP      <address@hidden>     <address@hidden>
Planix, Inc. <address@hidden>;   Secrets of the Weird <address@hidden>