Re: what's to stop a developer from nuking the repository?

[Greg A. Woods]

[ On Wednesday, January 21, 2004 at 13:12:05 (-0800), WJCarpenter wrote: ]
> Subject: Re: what's to stop a developer from nuking the repository?
>
> So, since it's unreliable to read between the lines to try to figure
> out what you're saying, is it that there are bugs in the canonical CVS
> *implementation* that lead to these problems?

Note first off that this discussion is as old as the hills.  I should
hope you can learn nothing new here that you couldn't learn by reading
archives of previous similar discussions in this and similar forums.  :-)

CVS is not a security application.  It was not designed to do any
authentication or authorization and it even relies entirely on the
underlying operating system for data integrity.  CVS is simply a program
that users can use to manipulate files that they could just as easily
manipulate using any number of other similar tools.  CVS has the
advantage that it can be split in two with one half running on a
"client" computer and the other half running on a "server" computer.
This split was designed to be used in such a way that logically what's
happening is that the user runs both halves of the program and then
connects them together so that they can communicate between each other.

The addition of pserver to CVS did not change any of the fundamental
design limitations in the original client/server mechanisms or how the
overall application works or what it dos.

CVS was designed only to be used by normal users who have already been
authenticated and authorized by the underlying operating system and this
restriction applies regardless of whether the client/server split is
being used or not.

As such if CVS is simply used as a normal application, as it was
designed to be used and as its implementers usually expect it to be
used, then there can be no bugs in the implementation that could ever
lead to any (unaccountable) security problems.  It's a logical
impossibility since all operations, buggy or otherwise, are done by an
already authenticated and authorized user (security is only half about
preventing bad things from happening -- the other half is about making
sure you can identify who or what is responsible when something bad does
happen).  CVS was designed and implemented with the assumption that all
responsibility for all aspects of security reside in the operating
system(s) that CVS is running within.

However pserver is just a lame attempt to provide authentication and
authorization inside the application.  Furthermore the way this has been
implemented makes it really easy to use in such a way that all internal
authenticaion and authorization is invisible to the underlying OS where
it matters -- i.e. the underlying system sees all operations on the
repository occuring as one opaque identity.  Thus there is no
accountability for those operations (beyond the slight possibility that
the connecting host and source port can be securely recorded with a
timestamp).  Although the pserver implementation does allow for CVS to
make use of one-to-one underlying user identities, this does nothing but
compromise most of underlying operating system's security because of all
the other flaws in the pserver design and implementation.

>  Is it by exploiting
> design flaws or bugs in the CVS implementation that pserver users can
> trivially forge identities, or do you mean more traditional and
> pervasive things like packet sniffing or snagging a peek at someone's
> .cvspass file?

One can indeed go on in this analysis to discuss other more specific
issues, such as the common use of a single OS-level user-ID, the fact
that plain TCP is used and thus the connection is susceptible to MITM
attacks), and the fact the authentication tokens are passed over the
connection "in the clear" and thus also suffer from MITM
vulnerabilities, the fact the authentication tokens are stored on the
client system in only barely obfuscated form, the fact that the majority
of repositories will have no special protection on their administrative
files (not that it would help in face of all the other problems), etc.,
etc., etc.  However to do so would be to miss the whole point here.

I think you need to take a dozen huge steps backwards and look at the
bigger picture.  Try to think about what CVS is really doing in terms of
file operations in the repository and keep in mind that the
client/server protocol is really just using remote job execution to
"extend" the user's operations between machines -- i.e. the CVS program
is split in two and the user runs one half of it on the local machine
and one half of it on the remote machine (with the key phrase here being
"the user runs").  The cvspserver extension to that protocol is just a
really cheap and stupid hack that allows CVS to directly use low-level
sockets to ask another user on a remote machine to run a program on that
remote machine instead of relying on external tools to do it as himself
in a (hopefully) more secure way.

The potential (and likelyhood) that there are bugs in the CVS
implementation itself which can be exploited to bypass the already
minimal pserver security is the very least of all of these issues.

CVS pserver should never have been invented, never mind implemented.  It
was a quick and dirty and stupid idea that solved a problem that existed
only because those people using "single user" client systems were too
lazy and cheap to implement even the trivial RSH protocol.  Good
security is never cheap (nor as simple as some people might wish it to
be), either in the real world or the computing world, especially when
public networks are employed.

There is no possible situation in which cvspserver can be used where
_any_ amount of accountability is required -- it is safe _only_ for
anonymous access, even if you're using host-based IPsec or SSH tunnels
between all clients and the server.  If someone has gone to that amount
of effort to secure their network then it would be very stupid of them
not to use RSH with real, unique, unix user identities for each person.

I urge anyone who has not understood my concerns but who has an interest
in learning a bit more about computer security to read Bruce Schneier's
most excellent "management level" overview of the subject of security in
digital computing and electronic networking:

        Secret & Lies:  Digital Security in a Networked World
        Wiley Computer Publishing
        published 2000
        ISBN 0-471-25311-1  (hardcover edition)

-- 
                                                Greg A. Woods

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