Re: New update to the CVS ACL patch to support user groups

[Greg A. Woods]

[ On Wednesday, July 25, 2001 at 00:49:56 (-0400), Larry Jones wrote: ]
> Subject: Re: New update to the CVS ACL patch to support user groups
>
> Even if you run pserver, it only runs as root long enough to validate
> the user's password then it switches to run as the user just like things
> like telnetd, ftpd, rshd, and sshd do.

The major problem is that cvs may not actually be permanently giving up
its root privileges on some types of systems.  Often the only way to do
that for real is to exec() another binary.  I guess CVS could exec()
itself, but that really begs the question of why CVS is doing anything
with security and not leaving it for some smaller and more dedicated
external program to do properly.

Of course the other problem with cvspserver is that it doesn't
necessarily switch to a real user, but rather just a pseudo user.  So,
you're damned if you do, and damned if you don't.  In the first case CVS
is opening all CVS user accounts on the machine to trivial attacks by
non-CVS users since it offers no network security whatsoever.  In the
second case you've no accountability since all users will end up using
the same system ID (and because the rest of the code is not expected to
be secure from attacks that would allow any one pseudo user to
effectively redirect blame for a successful attack on any other pseudo
user).

>  Yes, there is a potential for an
> error in the code allowing someone to circumvent security, but I fail to
> understand why people worry so much about CVS when they don't even think
> twice about rsh or ssh.  Especially since, as far as I know, there has
> *never* been a root exploit using CVS whereas there have been for all of
> those others.

The list of known exploits for a given set of programs depends almost
entirely on what crackers have attempted to exploit, not on what
potential exploits, or even known vulnerabilities, exist in those
programs.  I'm sure if something of the likes of sourceforge were to run
cvspserver you'd have seen exploits long ago.  However since they use
SSH any attacks against them have been against SSH, not against CVS (and
obviously not against anything to do with cvspserver).

There have been at least two, and maybe more, buffer overflows in the
AT&T UNIX "su" program.  One of them was exploited and fixed a couple of
years ago.  Another was apparently discovered and exploited again only
recently.  All the time before the two exploits the vulnerabilities
existed (in what some would call "plain open view", even though in that
case the code is proprietary).

In other words your logic is invalid.  Indeed in the security world the
opposite is true.  SSH in particular is much more secure and infinitely
better suited for use with CVS literally because it is a widely
deployed, used, and hacked upon, and because it has been successfully
exploited and subsequently fixed.  The more focus there is on a
particular security program, the better it becomes.  Since cvspserver
code isn't widely known, and even more rarely used in any place where
security counts, no attacker has focused on it as a potential weak link.

There are so many problems with cvspserver, in both its implementation
and in its very concept, that in the face of having multiple
alternatives already working in its place, one so nearly infinitely
better that not using it is nearly criminal(*), the mere continued
existance of the cvspserver code is not only unjustified, but does
unjustice to all CVS users, and especially those who have been "tricked"
into using it (often by its mere presence).  If people really want the
simplicity and lack of security they can use rsh instead of ssh.

(*) not taking reasonable measures to protect your systems may lead you
to be charged (or at least held paritally liable) too if they are proven
to have been used in committing some other criminal act.

-- 
                                                        Greg A. Woods

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