[16007] in bugtraq
Re: cvs security problem
daemon@ATHENA.MIT.EDU (Greg A. Woods)
Sat Jul 29 16:20:03 2000
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000729150419.B5A598D@proven.weird.com>
Date: Sat, 29 Jul 2000 11:04:19 -0400
Reply-To: "Greg A. Woods" <woods@weird.com>
From: "Greg A. Woods" <woods@WEIRD.COM>
X-To: Tanaka Akira <akr@m17n.org>
To: BUGTRAQ@SECURITYFOCUS.COM
In-Reply-To: <hvor98djl34.fsf@serein.m17n.org>
[ On , July 29, 2000 at 19:18:39 (+0900), Tanaka Akira wrote: ]
> Subject: Re: cvs security problem
>
> 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.
I've not looked at how those guys have chosen to expose their systems
but I've personally found that giving reasonably secure anonymous
read-only access to a CVS repository is relatively easy. It does
require making a copy of the live repository that is normally committed
to (easy with CVSup), and a separate dedicated machine on which to
provide the service, and it does require that clients use SSH (yes you
can have anonymous single-command SSH access with a tiny patch to SSH).
> 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.)
So they've chosen to use cvspserver, eh?
Chroot is helpful, but unnecessarily complex given the risk analysis of
a system such as I describe above. It is better to assume shell access
is possible and simply eliminate any and all sensitive stuff from the
system in question. Then all you have to do is to regularly audit the
integrity of the repository you are publishing so that you don't end up
handing out something that you didn't intend to (such as a trojan! :-).
> 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?
It should be obvious once you realise just how many places CVS has for
injecting shell commands into various hooks. Your exploit finds only
the obvious easy hack but there are probably dozens of more difficult
hacks waiting to be found. The CVS code was not even designed to be a
secure subsystem, let alone audited to ensure that it is one.
> > 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.
Yeah OK. In fact I was one of the inventors of that method and I
published the first patch I know of that makes it possible to use SSH-1
that way in a semi-secure fashion. So yes, it can be made reasonably
secure. However you still have to consider that the CVS code itself may
be riddled with more traditional stack-related bugs and as such is still
really not all that secure -- i.e. you should never run anonymous CVS
access on any machine that is trusted in any way by any other machine.
You can then use this argument to turn around and show that the risks of
running cvspserver on an "isolated" lone machine that's been otherwise
stripped to the bone and hardened from a security P.O.V. are low enough
to be justified in the face of the convenience this adds to the user
group you're targeting such a service to.
The point is though that finding and demonstrating an "exploit" to CVS
is pretty well meaningless -- such exploits are assumed to exist from
the word go because CVS is expected, by design, to be run only by users
who already have full shell access to the server it runs on. The manual
is currently a lot more cagey about this issue, unfortunately, but I
think all of the CVS developers are reasonably well aware of it.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
