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

[Larry Jones]

Greg A. Woods writes:
> 
> The major problem is that cvs may not actually be permanently giving up
> its root privileges on some types of systems.

You could say the same thing about sshd, ftpd, etc.  Why pick on CVS?

> Often the only way to do
> that for real is to exec() another binary.

In my experience, none of the standard server daemons do that; they just
fork.  (Well, that's not quite true: daemons that provide shell access
do typically exec the appropriate shell.)

> 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.

On my system, sshd is 10% *larger* than cvs.

> 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 my book, that is the *only* reason to prefer ssh over pserver.  I
will readily agree, however, that it's a really good reason.

> 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.  

That's true; I intentionally overstated the case a bit to make my point.

> 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).

At the same time, pserver has a very simple authorization protocol that
has been examined very carefully any number of times, making any
potential buffer overflows (which is the most common type of exploit)
very unlikely.  Other protocols are much more complex, which increases
their potential vulnerability (witness the recently reported
vulnerability of BSD-derived telnetd's).

> 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).

Proprietary code doesn't get looked at as much as open code.  Being open
isn't a panacea, but it's a big step in the right direction.

-Larry Jones

It's no fun to play games with a poor sport. -- Calvin