CONDOR-2005-0003

Arbitrary commands can be executed with the permissions of the condor_shadow or condor_gridmanager'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 is 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.

high

Usually the condor_shadow and condor_gridmanager are configured to run as the "condor" user, and this vulnerability allows an attacker to execute arbitrary code as the "condor" user.

Depending on the configuration, additional 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 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 would also allow root access as most condor daemons are started with an effective uid of root.

The condor_shadow and condor_gridmanager allow the user to be notified by email of changes to the status of their job. Normally, the user's email address is derived from the user's account information, but the user is allowed to specify the email address for the notification with the "notify_user" submit file command.

Internally, when a notification is required, the application creates a string that contains the name of the mail executable ($MAIL), a subject ($subject) argument and the value of the notify_user command ($notifyUser). The string's value is of the form '$MAIL -s "$subject" $notifyUser'. This string is then passed to popen as the effective user of "condor," and the option for the executable to be a writer. The executable then writes the body of the email message to the file descriptor, closes the file descriptor and then the email is sent.

No checking is performed on the notify_user value, which allows a malicious value to have unintended consequences. The popen library call takes the command string passed to it and essentially does the equivalent of the following command line:

/bin/sh -c "$command"

With stdin or stdout of the command rerouted to the file descriptor returned by popen. If notify_user is set to 'user@example.com; evil_cmd', the email will be sent and evil_cmd will be executed with the effective user being "condor," as the command that the shell executes is:

/bin/mail -s "subject" user@example.com; evil_cmd

For instance, if evil_cmd is 'xterm', then an xterm will open with a shell logged in as the "condor" user.

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

failure to validate input
dangerous system call
shell metacharacter injection

The cause of this is failure to validate that the user supplied email address is valid and to quote or escape shell metacharacters passed to popen.

First, the value of the notify_user option in the submit file needs to be checked to make sure it looks like a real email address: no spaces, and/or metacharacters that are not normally found in an email address ('.', '@', '-', '_', etc.). If it does not match this pattern then the job should be rejected. Also, email addresses should be rejected if they begin with a '-' as they can be misintrepeted by the mail command as an option.

Second, user supplied data to the popen library call should be placed in single quotes to avoid misintrepation of the command to be executed. Single quotes should be placed around the email address in the command sent to popen, and single quotes, if they get through the above, should be 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, if not rejected by the first fix, would become:

/bin/mail -s "subject" 'user@example.com; evil_cmd'

This will cause the mail command to fail, since the email address is invalid, and access to the "condor" user will not be granted.

Third, popen should probably be changed to an in-house function that mimics popen, but allows the arguments to be passed as a vector containing one entry for the executuble 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.

Fourth, the subject should be enclosed in single quotes instead of double quotes to prevent problems in the future. Even though the subject is not user supplied, a change to make it so would enable this attack on the subject. Also, the subject should have single quotes escaped as above to prevent future problems if the subject were to include a single quote character.

Call to popen was replaced with new my_popenv and implements the third proposed fix above, which eliminates the use of the shell and mitigates the vulnerability.

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