[ On , August 7, 2000 at 03:51:42 (+0900), Tanaka Akira wrote: ]
> Subject: Re: patch to make CVS chroot
>
> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Greg A. Woods) writes:
>
> > See the recent thread on BUGTRAQ where someone "exposed" the
> > insecurities of cvspserver.
>
> No. That's *not* cvspserver problem.
>
> First half is a general server problem not restricted to cvspserver
Yes, it is a cvspserver problem, and *only* a cvspserver problem. The
number and consequences of bugs in any version of CVS not using
cvspserver are totally irrelevant from a security point of view because
the only way they can ever be exploited is by someone already
authenticated and authorised to execute code on the server in question.
This is because CVS, by design and implementation, assumes the user
already has shell access.
> and last half is client problem. They are not depended to cvspserver.
"client problem"? Perhaps you don't understand the limitations and
implications of using SSH (or indeed any reasonably powerful
client/server protocol implementation in a public network)?
> Sourceforge try to forbid executing programs other than cvs command on
> cvs server machine. Why cvs distribution shouldn't do similar
> challenge?
Actually what they say is that they've replaced the shell on their
server with a restricted shell that allows only SSH/CVS access. However
they still face several risks since it is clearly possible to coerce CVS
into executing rather arbitrary code on the server, not to mention that
anyone who's ever experimented with restricted shells on traditional
unix will know just how vulnerable they are to attack. The real
protection comes from the fact that SourceForge have given unique
system-level IDs to each developer and thus they can hold individuals
responsible for any unauthorised activities -- i.e. activities contrary
to their security policy.
Security does not come about from technical means alone, but lack of
sufficient and correct technical protections can make a security policy
impossible to enforce. SourceForge have chosen the correct balance.
Someone wishing to attack them would at this point be required to attack
the authorised clients, and thus be able to covertly bypass SSH -- or in
other words to use it to their own advantage without the knowledge of
the user at the client side. There is still accountability in this
scenario of course, but the users may not realise the level of
responsibility they've inherently accepted!
--
Greg A. Woods
+1 416 218-0098 VE3TCP <[EMAIL PROTECTED]> <robohack!woods>
Planix, Inc. <[EMAIL PROTECTED]>; Secrets of the Weird <[EMAIL PROTECTED]>
