CONDOR-2005-0001

Condor checkpoint server allows reading and writing of arbitrary files with the permissions of the condor_ckpt_server's effective uid (normally the "condor" user) from a remote machine with no special privileges. This can result in checkpoints being replaced with malicious versions, reconfiguring condor if the "condor" user owns the configuration files, or gaining access to system files which may aid in other attacks.

remote ordinary user with no Condor authorization

This vulnerability just requires network access to the ports that the condor_ckpt_server listens.

high

To exploit this vulnerability requires the ability to decode the condor_ckpt_server network protocol and to write a replacement client which sends invalid input to the condor_ckpt_server. This can be accomplished by reverse engineering the network communications between the condor_shadow and the condor_ckpt_server or by access to the source code.

high

Usually the condor_ckpt_server is configured to run as the "condor" user, and this vulnerability allows an attacker to read and write any files that this user would have access. This allows an attacker to read the checkpoint server's transfer log which contains enough details to read and write other user's checkpoints. It also allows access to other sensitive files on the system such as /etc/password which may help in other attacks.

Depending on the configuration of the checkpoint server, further more serious attacks may be possible. If the configuration files for the condor_master are writable by condor and the condor_master is run with root privileges, then root access can be gained. If the condor_ckpt_server binaries are owned by the "condor" user these executables could be replaced and when restarted arbitrary code could be executed as the "condor" user.

The condor_ckpt_server stores checkpoint files for Condor standard universe jobs. The checkpoint files are meant to be all stored within a subdirectory, ckptDir. The files themselves are stored in ckptDir/shadowIpAddr/owner/filename. The shadowIpAddr, owner and filename are all sent as separate arguments to the ckeckpoint server and in a normal condor_shadow, they are all valid values.

An attacker can send a message which contains a filename which use a series of parent directory path names, '../', to escape out of the ckptDir/shadowIpAddr/owner directory. The transfer log sits in the ckptDir directory so it is easily obtained. If the attacker has access to another machine in the cluster and configuration files are shared the value of ckptDir can easily be obtained otherwise it is fairly easy to determine the depth and to get the correct relative path to other system files.

failure to validate input
directory traversal

The protocol for the checkpoint server validates that the filename is a simple filename on the the client, but fails to do so on the server.

Modify condor_ckpt_server/server2.C to validate filenames before granting checkpoint requests. Get and put request shadow ip address, owner and filename should be verified to be a simple filename without any path component (no directory separator(s), '/', allowed) and should resolve to a regular file or a nonexistent file (do not allow a filename of '', '.' or '..').

Fix was applied as proposed.

This research funded in part by National Science Foundation under subcontract with San Diego Supercomputer Center.