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

[Greg A. Woods]

[ On Wednesday, July 25, 2001 at 15:08:20 (-0400), Larry Jones wrote: ]
> Subject: Re: New update to the CVS ACL patch to support user groups
>
> 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?

Sshd, ftpd, etc., are all widely used *security* programs that are
specifically examined day in and day out by security experts from a
security point of view.  CVS is not know as a security application.  I
pick on it because it's more likely to be vulnerable since fewer eyes
have looked at it from a security perspective.  It's also got inherent
design limitations that almost guarantee many vulnerabilities are wide
open to attack.  CVS should not ever do anything related to security
(just as it should not ever run even one single line of code as root!).
It's no more intended to to security sensitive operations than "cp" is.

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

Ftpd is about the only one of those that doesn't normally exec()
anything, and it's a special case too because it doesn't provide remote
execution (shell) features.  Yes, some older (and often frequently
exploited) versions do run some external programs, but only for some
specific commands.  Modern versions, like the one on NetBSD, don't ever
run any external programs at all -- every command is builtin.  All of
rshd, sshd, whatever's at the other end of stunnel, etc., all definitely
exec() some other program once the connection is established (though of
course the all fork first since they must continue to maintain and
manage the remote connection, as well as do the crypto stuff if session
crypto is in use).

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

Uh huh.  That's a pretty much meaningless metric though....  I don't
know anyone in the security community who would disagree that sshd is
way too big -- but it's one of the best solutions available today (and
you can't hope to implement complex cryptography with lots of complex
math using very large numbers without writing a lot of code).  TANSTAAFL

The crypto protocols used by SSH aren't all that different from those in
SSL, and much of the math is the same, so you can't expect sshd to be
small.  Just the crypto and key management in SSL accounts for over 100%
of the code in sshd (that's a statically linked sshd2, btw):

$ size /usr/local/sbin/sshd2
text    data   bss      dec  hex   filename
793519  22712   44220   860451  d2123   /usr/local/sbin/sshd2

text    data   bss      dec  hex   filename
159469  8916    1728    170113  29881   /usr/lib/libssl.so
668219  41700   8888    718807  af7d7   /usr/lib/libcrypto.so

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

It's actually an incredibly critical reason -- generically speaking over
80% of all attacks are inside jobs (and that's generally held to be a
statistic derived from publicly reported attacks -- nobody knows how
many unreported attacks occor, though guess from anonymous interviews
suggest far more of the unreported ones are inside jobs than of the
reported ones).  That reason alone is itself infinitely more than enough
of a reason to outright delete cvspserver from existance.  There's
simply no excuse for leading people down this particular garden path,
not when the monster hiding in the bushes at the end is so nasty.

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

The authorisation protocol in cvspserver is not where the problem lies.
You can examine it forever with an infinitely fine comb and you cannot
make CVS any more secure as a result.  It's all the rest of CVS, _and_
all of the possible programs that can be called from CVSROOT/*info,
where the problems lie.  You cannot hope to ever fix all that stuff
alone.

>  Other protocols are much more complex, which increases
> their potential vulnerability (witness the recently reported
> vulnerability of BSD-derived telnetd's).

The recent telnetd fiasco isn't really due to a protocol complexity
issue.  Of course plain old telnetd is equally evil from a security
perspective -- it is similar to cvspserver in that it offers absolutely
no network security whatsoever.  Anyone with two brain cells to rub
together has long ago turned it off or at least firewalled it into what
they hope is a highly trusted, private, local area network.  If anyone's
being compromised by the recent exploits to telnetd they either don't
have a single clue about network security, *OR* they've been led down
the garden path by their OS vendor.  No OS vendor worth their salt has
shipped a system with telnetd configured on by default for months now,
if not several years.

(Obviously there are still far too many clueless admins and OS vendors!)

If it's not obvious yet I'm saying that every CVS maintainer worth their
salt should be doing everything in their power to immediately remove all
trace of cvspserver from the main public CVS distribution on cvshome.org.

-- 
                                                        Greg A. Woods

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