[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers-public] Re: 2 security concerns: remote init, and disa
From: |
Sylvain Beucler |
Subject: |
[Savannah-hackers-public] 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 address@hidden 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
talk.
> 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.
Thanks.
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
Mas).
--
Sylvain
99_savannah2
Description: Text document
allow-root-regexp3.diff
Description: Text Data
cvs-1.10.8-rootfile.patch
Description: Text Data