CVS Security question
Hello,
I'm using cvs from Suse 8.2 (cvs-1.11.5-43), tried to check out some software
and was rewarded with the following result:
jmayer@alice:~/work/games/freeoxyd/enigma> cvs -t up
-> main loop with CVSROOT=:pserver:anoncvs@subversions.gnu.org:/cvsroot/enigma
-> Connecting to subversions.gnu.org(199.232.41.2):2401
can't create temporary directory /mnt/ramfs/cvs-serv22847
Permission denied
-> Lock_Cleanup()
jmayer@alice:~/work/games/freeoxyd/enigma>
So far I'd assumed that CVS does not try to access files outside my local
cvs tree. I'm especially astonished that the client allows access to
absolute file/path names.
It this behaviour acceptable? I think not, but then, that's just my
personal paranoid opinion.
Comments?
Ciao
Jörg
--
Joerg Mayer
* Joerg Mayer wrote on Wed, Jun 11, 2003 at 00:18 +0200:
jmayer@alice:~/work/games/freeoxyd/enigma> cvs -t up -> main loop with CVSROOT=:pserver:anoncvs@subversions.gnu.org:/cvsroot/enigma -> Connecting to subversions.gnu.org(199.232.41.2):2401 can't create temporary directory /mnt/ramfs/cvs-serv22847
So far I'd assumed that CVS does not try to access files outside my local cvs tree.
Well, for multiple purposes CVS uses temp files (probably in respect of $TEMP or so).
I'm especially astonished that the client allows access to absolute file/path names.
Yes, it is known that CVS offers access when giving write access to the repository. Check out possibilities of CVSROOT files, there a couple of nice things an intruder could use! CVS should be used in "trusted environments" only I think. Of course you can use systems features to secure it a little (chroot with local r/o NFS mount for an unpriviledged user and so on). oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Wed, Jun 11, 2003 at 12:47:44AM +0200, Steffen Dettmer wrote:
Well, for multiple purposes CVS uses temp files (probably in respect of $TEMP or so).
I'm especially astonished that the client allows access to absolute file/path names.
Yes, it is known that CVS offers access when giving write access to the repository. Check out possibilities of CVSROOT files,
As I wrote in my followup to my own post: The client does not try to actually access the file/directory outside the tree, so it looks like thing are ok after all and I just caused some unnecessary fuss :-(
there a couple of nice things an intruder could use! CVS should be used in "trusted environments" only I think.
Can you please explain a bit what you are meaning?
Of course you can use systems features to secure it a little (chroot with local r/o NFS mount for an unpriviledged user and so on).
I think you are talking about securing a CVS server - the client should
not be allowed to write anywhere outside (aka closer to the root) its
current directory - everything else would make me and probably many other
people stop using the cvs client immediately.
Ciao
Jörg
--
Joerg Mayer
* Joerg Mayer wrote on Wed, Jun 11, 2003 at 00:59 +0200:
On Wed, Jun 11, 2003 at 12:47:44AM +0200, Steffen Dettmer wrote:
Well, for multiple purposes CVS uses temp files (probably in respect of $TEMP or so).
I'm especially astonished that the client allows access to absolute file/path names.
Yes, it is known that CVS offers access when giving write access to the repository. Check out possibilities of CVSROOT files,
As I wrote in my followup to my own post: The client does not try to actually access the file/directory outside the tree,
Ohh, the client... yes, I think it was a server message, as the filename "cvs-serv" suggests :-)
there a couple of nice things an intruder could use! CVS should be used in "trusted environments" only I think.
Can you please explain a bit what you are meaning?
When abusing a CVS server, someone could add and (server-side) execute scripts, do it does not really matter what CVS allows :-) Abusing a client with a software source repository is also quite easy, maybe adding a "trojan" into a configure M4 or such.
Of course you can use systems features to secure it a little (chroot with local r/o NFS mount for an unpriviledged user and so on).
I think you are talking about securing a CVS server - the client should not be allowed to write anywhere outside (aka closer to the root) its current directory - everything else would make me and probably many other people stop using the cvs client immediately.
Well, I would not rely on that, but usually it should not do that, yes. CVS is not designed as secure system but works well together with SSH. In almost any case, the CVS server could attack you by simply trojaning the delivered data. So be careful, as always :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
On Wed, Jun 11, 2003 at 12:18:50AM +0200, Joerg Mayer wrote:
jmayer@alice:~/work/games/freeoxyd/enigma> cvs -t up -> main loop with CVSROOT=:pserver:anoncvs@subversions.gnu.org:/cvsroot/enigma -> Connecting to subversions.gnu.org(199.232.41.2):2401 can't create temporary directory /mnt/ramfs/cvs-serv22847 Permission denied
OK, some further investigation showed, that this was a false alarm!
Strace shows, that the message is generated *without* trying to actually
create/access that directory.
very much relieved that it was my stupidity instead of an insecure client :-)
Ciao
Jörg
--
Joerg Mayer
On Mit, 11 Jun 2003, Joerg Mayer wrote:
-> Connecting to subversions.gnu.org(199.232.41.2):2401 can't create temporary directory /mnt/ramfs/cvs-serv22847 Permission denied
are you sure thats local? usually thats a message from the cvs server, it seems to be a temporary load problem (out of memory on the tmpfs). the client is pretty dumb and does not create a directory in $TMP.
So far I'd assumed that CVS does not try to access files outside my local cvs tree. I'm especially astonished that the client allows access to absolute file/path names.
the client does not allow access to absolute pathnames as far as I know. the protocol works the opposite way (so its much easier to get access to a file outside CVSROOT on the server if its not secured properly).
It this behaviour acceptable? I think not, but then, that's just my personal paranoid opinion.
if you don't trust the CVS server, then better don't use it (and especially don't compile and run the software you got from the CVS server :) ). -- Dirk
participants (3)
-
Dirk Mueller
-
Joerg Mayer
-
Steffen Dettmer