CONDOR-2006-0004

In the rare configuration that CLASSAD_SCRIPT_DIRECTORY is set in the Condor configuration, arbitrary executables can be executed with the permissions of the condor_negotiator and condor_shadow's effective uid (normally the "condor" user). This can result in a compromise of the condor configuration files, log files, and other files owned by the "condor" user. This may also aid in attacks on other accounts.

local ordinary user with a Condor authorization

This vulnerability requires local access on a machine that allows running a condor_schedd, to which the user can use condor_submit to submit a job.

low

To exploit this vulnerability requires only the submission of a Condor job with an invalid entry, and the CLASSAD_SCRIPT_DIRECTORY to be configured. Normally, CLASSAD_SCRIPT_DIRECTORY is not defined, preventing this vulnerability.

high

Usually, the condor_negotiator and condor_startd are configured to run as the "condor" user, and this vulnerability allows an attacker to execute arbitrary executables as the "condor" user.

Since log files and other data files are owned by the "condor" user, they can be arbitrarily modified. Also, if the condor_negotiator is started as condor, the condor_negotiator can be attacked and the condor_negotiator is central to the operation of a Condor system.

Depending on the configuration, further more serious attacks may be possible. If the configuration files of the Condor system are writable by condor and the condor_master is run with root privileges, then root access can be gained. If the condor binaries are owned by the "condor" user, these executables could be replaced, and when restarted, arbitrary code could be executed as the "condor" user. This also would allow root access as most Condor daemons are started with an effective uid of root.

The classad mechanism allows a site to configure a directory of external scripts using the CLASSAD_SCRIPT_DIRECTORY variable. If this is set, then expressions containing terms of the following form script("arg0", "arg1", "argN"), will end up making a call to popen, using the first argument combined with the CLASSAD_SCRIPT_DIRECTORY value to form the name of a script and the remaining arguments are passed to the script with strings surrounded by double quotes.

Since the full path of the script to be executed is the concatenation of the value of CLASSAD_SCRIPT_DIRECTORY, a '/' and the script name (first argument to the script function), the script to execute can be outside of the CLASSAD_SCRIPT_DIRECTORY if the script name contains parent directory components.

For instance, if you wanted to execute /usr/bin/xterm -display example.com:0.0, and the CLASSAD_SCRIPT_DIRECTORY were set to /home/condor/scripts, then the following term in a classad would accomplish the goal:

script("../../../usr/bin/xterm" "-display" "example.com:0.0")

failure to validate input
dangerous system call
directory traversal

The cause of this is failure to validate the name of the script to make sure opening a script outside of the CLASSAD_SCRIPT_DIRECTORY is not allowed.

Only allow the script name to be a simple filename. Do not allow a directory separator to appear in the script name, or if you do wish to allow subdirectories in the CLASSAD_SCRIPT_DIRECTORY, then the filtering could be done on parent directory entries in the path.

This feature was removed from the system due to security and lack of use. It was done before the report was given to the Condor team.

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