distcc security notes

distcc is intended to be quite secure when used according to the documentation, but it must be properly configured.

Anyone who can connect to the distcc server port can run arbitrary commands on that machine as the distccd user. If you are not using SSH, you must use the --allow rule and/or firewall rules to limit access to port 3632. Since version 3.0, distccd now enforces that, refusing to run if the --allow option is not specified.

Someone has written a program to attack unprotected servers. To prevent this attack, use network access control or SSH (which is much slower).

Installation or use of any software caries a certain risk, which should be assessed by the machine operator.

distcc allows remote execution of compilation jobs. This introduces a trust relationship between the client and server machines. The client completely trusts the server to compile code correctly. A corrupt server could introduce malicious code into the results, or attack the client in other ways. The server completely trusts an authorized client. A malicious client could execute arbitrary commands on the server.

distcc supports a choice of two network transports: a simple TCP protocol (normally on port 3632), and connection over SSH or a similar secured connection.

The distccd TCP server does not run as root. If started by root, before accepting connections it gives away its privileges and changes to either the distcc or nobody user, or to a user specified by the --user option.

The distcc client may be run as root. Compiling or doing other unnecessary work as root is generally discouraged on Unix, but distcc permits it because some package installations require it.

In TCP mode network transmissions are not encrypted or signed. An attacker with passive access to the network traffic can see the source or object code. An attacker with active access can modify the source or object code, or execute arbitrary commands on the server.

The TCP server can limit clients by either checking the client address, or listening only on particular IP interfaces. However, in some circumstances an attacker can spoof connections from a false address. If such a situation apply to your network then IP-based access control is not sufficient.

In TCP mode there is no way to limit access by user, rather than by host.

IPSec or IPv6 would probably also help, but nobody has reported testing it with distcc.

In SSH mode the server is started by each user under their own account on the server. There is no long-lived daemon. Connections are authenticated and encrypted. Every user is allowed only the privileges that their normal account allows.

Because the server and client necessarily trust each other, there has been no security audit of the code that runs after a connection is established. It is possible that a hostile server could gain control of a client directly, as well as modifying the object code.

If the DISTCC_CMDLIST environment variable is set when invoking distccd, distccd will only execute commands from that list. (The RPM and Debian distributions of distcc set this variable via the /etc/distcc/commands.allow.sh file which is sourced by /etc/init.d/distcc). This mechanism can be used to only allow the execution of compilation commands rather than arbitrary commands. However, this should not be relied on as a security measure, because gcc is not secure against hostile input, and it might be possible for an attacker to gain control of the gcc process through a carefully crafted input file or command line. You should assume that anyone able to submit jobs is able to execute arbitrary operations under the account used by distccd.

It has been suggested that distccd should take a simple username/password authentication mechanism, but this would give a false sense of security. If you cannot trust your network, the only sensible policy is to use SSH.

Some people have proposed that the client should check whether a server is trustworthy by re-running compilations on a different server. This approach can be useful in some distributed-computing problem spaces such as SETI@home, but not practical for distcc. Firstly, the damage from a single compromised object file is very high, so every single file would have to be extensively checked. Secondly, the performance constraints are such that building every single file two or more times would often make distribution worthless. Thirdly there would sometimes be false alerts from minor differences in gcc patchlevel that are not visible in normal use but that do change the output file at a byte level.

For practical advice, see this description of how to secure distcc using chroot and OpenVPN.