CONDOR-2009-0001

An ordinary user that can submit jobs to a Condor system can modify any of the attributes of its Condor job. This in turn can be used to compromise other users' jobs, which can lead to a complete compromise of the local accounts in the Condor system other than the local privileged accounts (root on POSIX systems and local\Administrator on Windows).

ability to submit to a Condor schedd

This vulnerability requires local access on a machine where the user has write authorization to the condor_schedd (i.e., a host and account where the user can submit a job).

low

The use of ordinary condor command line tools is all that is required to exploit this vulnerability.

high

This vulnerability can result in a complete compromise of the local accounts in the Condor system other than local privileged accounts (root on POSIX systems and local\Administrator on Windows). This includes control of users' jobs and the Condor daemons.

Condor Wiki Ticket #1018

As of 7.2.0, the queue super user has the power to change the value of Owner to any owner who has a job in the queue or who has ever had a job in the queue during the life of the current running schedd. This was added for JobRouter. Prior to version 7.2.0, a user could always change the value of Owner to the Condor admin user.

The problem with this is that condor_shadow authenticates to the schedd as the condor user (always a super user) when performing set_job_attr operations on behalf of chirp calls made by the job. Therefore, the job can change its own Owner attribute, requeue itself, and gain access to somebody else's account. It can only gain access to accounts that have submitted a job to condor or to the "condor" user.

Condor prevents jobs from running as the local privileged accounts (root on POSIX systems and local\Administrator on Windows), so gaining access to the these account is not possible directly. It may be possible by submitting jobs that run as other local accounts that can then be used to gain access to the local privileged account.

This example bash script below will submit a job. It will be submnitted as the local user, but after it completes it the "Owner" will be set to the Condor user.

    #!/usr/bin/bash

    # create a submission file

    cat <<EOF >>test.sub
    universe = vanilla
    +WantIOProxy = True
    executable = $ENV(CONDOR_CHIRP)
    arguments = set_job_attr Owner \"$ENV(CONDOR_USER)\"
    when_to_transfer_output = ON_EXIT
    leave_in_queue = JobStatus==4
    queue
    EOF

    
    # set some variables and submit the job

    export CONDOR_USER=`condor_config_val schedd_log | xargs ls -l  | awk '{print $3}'`
    export CONDOR_CHIRP=`condor_config_val libexec`/condor_chirp
    condor_submit test.sub
    

not properly dropping privileges

Chirp connections from a running job connect to the schedd via the shadow. The shadow authenticates with the schedd as the "Condor" user (the privileged account in Condor system). The running job then assumes the privileges of the Condor user.

In all fixed versions of Condor, the privileged attributes are now immutable including the owner attribute, which will prevent this problem.

Going forward, starting with version 7.5.0, Condor was further changed to add a qmgmt command that allows the queue super user to reduce privileges to that of an ordinary user so that all subsequent operations in the qmgmt session are done as though by the other user (like seteuid() in unix). The job queue updater used by the shadow (and local starter) does this in all cases immediately after establishing a qmgmt session. This addresses the problem of chirp but also reduces risk of other operations being allowed that should not be.

Changing the shadow to authenticate as the user instead of condor is another possible solution. This is problematic, because not all authentication methods support authenticating as the user from within a condor daemon. For those methods that do support authentication based on priv state (such as FS), the security session cache does not keep track of what priv state was used to create the session, so we would either need to fix that, or change all shadow --> schedd communication to be done as the user (including the daemon keepalive and possibly other things I am forgetting).

Removing the power of the super user to directly change Owner is another option. In fact, with the "seteuid()" qmgmt operation, the JobRouter should no longer need the queue super user to have the power to directly set Owner. However, changing the JobRouter seems like a larger than necessary change in the stable series, so this should probably be done in the current development series, leaving the extra super user power as is in the stable series if not beyond.