[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Savannah-hackers-public] Re: 2 security concerns: remote init, and disa
[Savannah-hackers-public] Re: 2 security concerns: remote init, and disabling CVSROOT/passwd
Mon, 7 May 2007 23:52:41 +0200
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
> 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
> 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
> 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:
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
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.
> >- 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).
> >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
Description: Text document
Description: Text Data
Description: Text Data