RfD: Debian is not randomly installing services
-----BEGIN PGP SIGNED MESSAGE-----
The most recent security post on bugtraq reminds me on this proposal.
I have noticed that Debian packages are randomly installing services
(except for rwhod).
What I mean is that there are some Debian packages that contain both a
server and a client. Often the server is installed, too, and the user
isn't asked for permission at all.
As an example, I was going to use cvs and by installing cvs and rcs
Debian enables cvspserver on my machine - which turns out as a
security hole now and I have to log in on all machines to disable
I hate to have disable all of the services on a newly installed
machine. This is one very bad thing I found on Suns where there are
several daemon and open ports. I really don't like this behaviour.
Therefore I recommend changing our policy slightly. I'll write down a
paragraph for our policy later (or would you like to step forward,
If a package contains both a server and a client, and the server
opens another possibility to reach the system (via network, modem,
radio &c.) the server will not be enabled without asking the user
for his permission.
The situation looks completely different if the server has its own
package, like `msqld' for the server and `msql' for the client.
As master is down at the moment firstname.lastname@example.org doesn't work.
Rince has already forwarded the most recent bugtraq mail to that
address but it can't get through the downed master so I'm appending it
Date: Fri, 27 Jun 1997 09:59:02 -0500
From: Aleph One <aleph1@DFW.NET>
Subject: Security hole affects many cvs pserver installations
Cyclic Software has received reports of a security hole that affects
many CVS servers using the pserver authentication method. We
recommend that sites take appropriate actions depending on their
situation and security needs.
Under some circumstances an attacker can supply an alternate
CVSROOT/passwd file, which a CVS pserver server will use to give the
attacker access to any user on the system.
Vulnerable versions of CVS include 1.7, 1.8, 1.9 and 1.9.8.
Version 1.9.10 is not vulnerable provided that the advice in section
IV "Additional Solution" is followed.
Those not running a pserver server are safe from this problem. If
you aren't sure whether you are running pserver, look at
/etc/inetd.conf for mentions of CVS. Pserver typically runs on port
Note that on some systems the inetd configuration file may have a
different name or be in a different location. Please consult your
documentation if the configuration file is not found in
This attack requires an intruder to be able to make a network
connection to a vulnerable CVS server. This means that some sites,
depending on their security configurations and policies, may not have
an urgent need to take action.
If the machine running the CVS server also has running a service which
allows for file upload (for example, anonymous FTP if configured to do
so), then anyone who has the ability to upload files can gain full
access to the server system. If there is no service which allows file
upload, then users who already have some access to the server system
can gain access as any other user, including privileged users.
Upgrade the CVS server to CVS 1.9.10. There is no need to upgrade
CVS clients. When you upgrade you will need to add --allow-root to
inetd.conf as described in the CVS 1.9.10 distribution.
Note that CVS 1.9.10 is an interim release. It has not received as
much testing as a released version such as CVS 1.9, so people who are
not vulnerable to this security hole may wish to stay with CVS 1.9.
CVS 1.9.10 is available for free download from
http://download.cyclic.com or ftp://download.cyclic.com.
IV. Additional Solution
Even if you upgrade to CVS 1.9.10, there is still an issue with the
repository permissions (as long as you continue to use pserver). You
probably want to change the permissions on the $CVSROOT and
$CVSROOT/CVSROOT directories and the $CVSROOT/CVSROOT/passwd file as
Note that because the `$CVSROOT/CVSROOT' directory contains
`passwd' and other files which are used to check security, you
must control the permissions on this directory as tightly as the
permissions on `/etc'. The same applies to the `$CVSROOT'
directory itself and any directory above it in the tree. Anyone
who has write access to such a directory will have the ability to
become any user on the system. Note that these permissions are
typically tighter than you would use if you are not using pserver.
Using some authentication mechanism other than pserver avoids the
problem completely. In particular, running CVS over a remote
execution program such as rsh, kerberized rsh, or ssh involves no
network security implications beyond those involved in running the
remote execution program in the first place.
VI. For future information
For future updates on CVS security, consult http://www.cyclic.com. In
particular, there is a security page at
-----BEGIN PGP SIGNATURE-----
-----END PGP SIGNATURE-----
/ Martin Schulze * email@example.com * 26129 Oldenburg /
/ The MS-DOS filesystem is nice for removable media /
/ -- H. Peter Anvin /
TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to
Trouble? e-mail to firstname.lastname@example.org .