On Fri, Aug 04, 2000 at 09:29:06PM -0400, Greg A. Woods wrote:
> The only 100% guaranteed way to be sure of this is to *NEVER* run CVS as
> root, not ever, not for one CPU cycle, period!
Yes that's true. However:
> You could, if you really insist on using the inherently broken concept
> of cvspserver, run CVS setuid to some non-root user (eg. "cvsauth") that
> is privileged enough that it can just barely read the CVSROOT/passwd
> file; and of course have it give up its meager privileges once it's
> authenticated and authorised the connecting user and return to being
> just the user it was called as from inetd (eg. "cvsuser").
I can't do that because I need to control access to portions of the
repository using groups. I wish CVS had this capacity internally but
it doesn't--I have to rely on Unix groups and that means I have to
run CVS as root.
Different groups of people own different parts of my CVS tree. Some
people have more access than others. Some people have only anonymous
access. Others can write to almost anything. If I shut these people
out of my CVS archive on the grounds of it being "insecure" and them
not being able to run CVS over "ssh", then I cut off valuable development
resources that are worth a lot more to me than the security of one
unimportant box.
> Yes this does imply that if you want to benefit from the relativley weak
> advantages of chroot you have to run a setuid-root wrapper that can call
> chroot() directly from inetd (such a wrapper isn't exactly easy to write
> correctly, and the one mentioned on the list may in fact be already
> suitable, but it's on heck of a lot easier to do than it is to modify
> CVS to make it secure!).
Chroot, when used properly, and on a good OS, is adequate for locking up
a *non-root* process. It's true that if there is a flaw in the auth portion
of the pserver request allowing someone to execute arbitrary code then
they can escape from the chroot.
However I feel my risk is substantially less than it was: the attack has
to overcome the chroot(), and it is limited to the auth segment of the code.
Theoretically possible yes. Practically much less likely to happen than
the situation without this patch.
> Putting chroot() directly in CVS is *WRONG* *WRONG* *WRONG* *WRONG*
> because it absolutely requires that you run CVS as root for some period
> of time and thus virtually guarantees that someone might be able to
> execute unauthorised bits of code as root! If you do this you are
> almost certain to gain infamy on BUGTRAQ.
Unfortunately the way Unix is written there is no other way to gain
access to setgid. If there were, my problem would be solved. If CVS
had some other kind of group access control technology in it that
would also solve my problem, but it doesn't.
> In fact the/any person who thought it was safe to run cvspserver as root
> in the first place should probably never be allowed to touch security-
> sensitive code ever again! There's absolutely no need for using root in
> an application like CVS -- that was just a *VERY* bad design decision.
The cost of a breakin here is minimal. It's on a machine running nothing
important other than the CVS server. So the cost is that I have to
reinstall the machine.
I use the machine for other things as well, but none of it very important.
> In the end the only real solution is to ditch cvspserver completely and
> revert to using the designed for external transport mechanisms that use
> real system authentication and authorisation, such as SSH or whatever.
Which is not supported by the majority of my CVS clients (who are
external users outside my organization and I don't want to spend
time on the phone with them helping them get WinCVS working with
ssh, if WinCVS actually ever successfully works with ssh at all).
I can't force them to switch to Unix, install loads of specialized
software, or fix WinCVS so that it's ssh mode actually works. I do
*have* to provide them with access to my CVS tree or my project will
die--not an option.
CVS needs a general solution to this problem. What I did isn't ideal, in
any sense, but it is about 1000 times better than doing nothing.
Here's the main problem:
The CVS community has sat around gasping about this problem for a
*very* long time now: years and years, and nothing whatever has
been done about it. I was going to work on a fix before, but I ran
into heavy flak from everyone on this list who was absolutely sure
that "ssh" was the right way to go. Well ssh isn't the right way
to go, and I say that based on the fact that 90% of my clients
can't figure out how to get it work. A solution that doesn't work
is no solution at all.
What CVS really needs is an external module which handles authentication,
has support for ssl, performs the chroot/setgid on auth and then invokes
the ordinary cvs to do the processing, and is short enough that it
can be effectively audited. CVS doesn't have that, and my guess
at this point is that it never will: in the meantime, my life goes
on and I had to do something.
Justin
