CONDOR-2006-0003

In the rare configuration that CLASSAD_SCRIPT_DIRECTORY is set in the Condor configuration, arbitrary commands 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 code 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.

Other than strings being surrounded with double quotes, the arguments are not escaped and quoted, or checked for shell metacharacters. The library call of popen($command) does the equivalent of:

/bin/sh -c "$command"

With stdin or stdout of the command rerouted to the file descriptor returned by popen. If CLASSAD_SCRIPT_DIRECTORY had the value "/condor/scripts", and the term were script("myscript", "\";evil_command\""), the resulting operation would be equivalent to:

/bin/sh -c '/condor/scripts/myscript "";evil_command""'

Other methods of attack are also possible, including backquotes and other shell metacharacters that still have special meaning inside of double quotes.

A similar attack can be done on Windows using the '&' metacharacter instead of the ';' metacharacter.

dangerous system call
shell metacharacter injection

The cause of this is failure to properly quote user input passed to popen library call that allows shell metacharacter injection to occur.

User supplied data to the popen library call should be placed in single quotes to avoid misinterpretation of the command to be executed. Single quotes should be placed around each argument and the script name sent to popen as they prevent the interpretation of most shell metacharacters. The value placed in single quotes also needs to have any single quotes escaped by replacing them with '\'' (this closes the single quote, inserts a \-quoted single quote and reopens the single quote). In the the example above, the command to be executed would become:

'/condor/scripts/myscript' '";evil_command"'

This will call the script with a single argument that happens to contain 2 double quotes and a semicolon, and will not result in a vulnerability.

A better solution would be to replace the call to popen with a routine that mimics popen, but allows the arguments to be passed as a vector containing one entry for the executable and one for each argument individually, so the use of /bin/sh is not required. This can be done with a pipe, fork, and execv or execve system calls so the calling environment and argument interpretation can be better controlled. This would eliminate the need to deal with quoting at all.

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.