Re: cvs security problem

[Tanaka Akira <akr () M17N ORG>]

In article <20000728200315.6621C8B () proven weird com>,
  woods () weird com (Greg A. Woods) writes:

> Yeah.  So?  This is meaningless.  CVS is not designed to prevent this.
> In fact quite the opposite -- it is assumed that CVS users with commit
> access do have shell access to the CVS server.

I agree that the problem is meaningless if a server provides general
shell access for committers.  But there are challenges to setup cvs
server without general shell acess.

http://www.prima.eu.org/tobez/cvs-howto.html
http://www.openbsd.org/anoncvs.shar
http://guv.ethz.ch/~flip/cvsd/

They prevents general shell access using chroot.  But unfortunately,
they are vulnerable as the first problem I described.
(The problem is effective even if /bin/sh is not exist.)

> In fact normally the "cvspserver" method of accessing a CVS repository
> should only ever be used for anonymous read-only access, and even then
> it is well known that shell access to the server may be possible (under
> the user-id that the cvspserver daemon runs as, of course).

I agree that pserver shouldn't be used other than anonymous read-only
access because pserver transmits passwords in plain text.  But I
didn't know shell access is possible.  Would you explain a way to do
it?

> A properly configured CVS server will use a secure remote execution
> facility (such as SSH) which by definition means that any committer will
> have shell access to the server, but of course only under a properly
> authorised user-id -- i.e. they'll be accountable for their actions.

No. cvs via ssh can be configured without shell access.  For example,
a option `commands="cvs server"' in authorized_keys prevents execution
other than cvs server.

http://kitenet.net/programs/sshcvs/
--
Tanaka Akira