[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2 security concerns: remote init, and disabling CVSROOT/passwd

From: Sylvain Beucler
Subject: Re: 2 security concerns: remote init, and disabling CVSROOT/passwd
Date: Mon, 7 May 2007 23:52:41 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

On Mon, May 07, 2007 at 11:03:47AM -0400, Derek Price wrote:
> Excuse the cross-post.  Development discussions are more appropriately 
> sent to bug-cvs.  Please delete info-cvs@nongnu.org from any replies.

Sorry, this started in my head as "how would you recommend running CVS
in order to avoid local access", and it subrepticiously morphed to dev

> Sylvain Beucler wrote:
> [summary of remote `cvs init' exploit]
> >Currently the command is disabled for remote access, using a
> >quick'n'dirty patch ("if (server_active) exit(EXIT_FAILURE)").
> >
> >What would you recommend? Are there legitimate use for remote 'init'?
> >I wouldn't like users creating their private repositories at Savannah
> >either.
> No, there really aren't any legitimate uses for `cvs init' via remote 
> access.  Anyone who is creating a new CVS repository or upgrading a CVS 
> server to use a new CVS executable presumably has local access to the 
> machine anyhow.
> I've recommended something like your `hack' to customers in the past, 
> but I've never actually installed the change into CVS itself until a few 
> minutes ago (in stable - the merge to 1.12.x is still running through 
> the regression suite).  It should be incorporated into the 1.11.23 & 
> 1.12.14 releases.


By the way, I see that cvsnt does it somehow differently, by checking
whether 'cvs server' is run against a valid cvs repository - and fails
with an non-existing one.

> >Since we have numerous repositories, we hit command line limits for
> >pserver --allow-root (2700 * 2 * 20 / 1024 = 105KB, not counting
> >aliases). Besides, it is not really easy to change the 'pserver'
> >command line in xinetd each time a new project is created.
> >
> >To overcome this, we used Vincent Caron's patch
> >(https://mail.gna.org/public/savane-dev/2005-08/msg00042.html).
> For starters, I've heard of an --allow-root-file patch which allows all 
> the roots to be specified in a file with only the file name being 
> specified on the command line.  The only reference I found to it in a 
> quick google search was in a savane-dev archive, however, and there were 
> some broken links so I couldn't figure out how to get the attachment:
> https://mail.gna.org/public/savane-dev/2002-04/msg00373.html

I like it less, because the list of repositories has to be regularly
regenerated. That's also a X00kB file to read at each request, but
maybe that doesn't really matter.

I attach the patch (alternatively you can wget
http://savannah.gnu.org/file/cvs-1.10.8-rootfile.patch?file_id=1 -
given the file id, you can even guess the patch's venerable age). Its
origin is unclear.

Having looked at cvsnt, that's more or less what it does: all
repositories are either mentioned with --allow-root (deemed
deprecated) or listed in /etc/cvsnt/Pserver.

> [elide well known pserver abuses]
> >Currently there's a hard-coded patch at Savannah which prevent parsing
> >CVSROOT/passwd for pserver; the root-owned pserver is also ran behind
> >the firewall, as it's only used internaly, and only for web
> >repositories (the public pserver is ran as user nobody). Of course
> >that's a pretty brute way to handle the situation.
> [snip]
> >- Permit the CVS administrator to disable CVSROOT/passwd
> >  authentication with a pserver command-line switch (a cracker might
> >  still switch to an unsecure PAM scheme, but that's less
> >  straightforward).
> >
> >- Or more generaly, specify the allowed authentication scheme in the
> >  pserver command line (this would be easier to secure) - overriding
> >  CVSROOT/config.
> Could you send me the patch you mention?  I should be able to adapt it 
> to a command-line switch pretty easily.

I attach 99_savannah2, a patch against cvs-1.12.9 for Debian Sarge.

I just saw that there is now a way to specify a site-wide 'config'
file (-c switch); this could also be a cvs.conf option, something like
AnonymousAuth=yes (accepts 'anoncvs' and 'anonymous' only) and
CvsAuth=no (not CVSROOT/passwd processing).

> >[1]
> >http://web.archive.org/web/20040327105943/http://ccvs.cvshome.org/issues/show_bug.cgi?id=41
> >Unfortunately the old cvshome issue tracker appears to be down, and I
> >can't grab the patch anymore. Does somebody have it?
> I pulled out and attached both patches from that issue from a backup of 
> the old Issuezilla.
> I don't know if you still want the --allow-root-regexp patch merged into 
> 1.12.x, but I found some discussion in the archives and it sounds like 
> we were waiting on documentation and test cases for the change.

Yeah, that's what the bugzilla page says - I'll look into it. (Now the
processing is less straightforward since the list of allowed roots
changed from a table to a linked List. Maybe the list of paths could
be realpath'd, too)

For the record I also attach a more recent (2004) version of the patch
that I just got from Christian Bayle (but the patch is from Roland


Attachment: 99_savannah2
Description: Text document

Attachment: allow-root-regexp3.diff
Description: Text Data

Attachment: cvs-1.10.8-rootfile.patch
Description: Text Data

reply via email to

[Prev in Thread] Current Thread [Next in Thread]