The --chroot flag also significantly reduces the risk here as well. Only
those executables you place into the chroot area are available for use. If
you don't need scripts in your CVS installation you could also do without
having any binaries at all--you could even place the chroot root in on
a mount point that does not permit executable programs.
In order to break in with the --chroot flag in place you have to smash
the stack somehow prior to CVS dropping root privileges. After it's
dropped privileges, it doesn't matter whether or not you can execute
external programs:
-- You can't write anything outside of the CVS area
-- The chroot area may not permit executable programs
I see this as a big win.
Justin
On Mon, Aug 07, 2000 at 12:09:47AM +0400, Alexey Mahotkin wrote:
> >>>>> "GAW" == Greg A Woods <[EMAIL PROTECTED]> writes:
> GAW> See the recent thread on BUGTRAQ where someone "exposed" the
> GAW> insecurities of cvspserver.
>
> I've always thought that this is not limited to pserver itself. cvs
> over rsh/ssh should also suffer from this problem, because
> "Checkin-prog"/"Update-prog" are not parts of ":pserver:" protocol.
> They are parts of the "CVS client/server protocol", as described in
> cvsclient.info.
>
> ":pserver:" protocol covers only parts between "BEGIN AUTH REQUEST"
> and "END AUTH REQUEST", that consists mostly of sending login name and
> password.
>
> So the "design flaw" is just in so much trusting strings passed by
> remote clients and not in the :pserver: architecture, which is
> adequate enough.
>
> So when that will be fixed (and the simplest patch is included into
> the advisory), cvs-nserver will too be fixed. For now I will not
> release patched version of cvs-nserver until something more official
> about it comes out (cvs-1.10.9, for example).
>
> --alexm
