CONDOR-2006-0005

A user that is able to submit a Condor job can modify jobs or add arbitrary jobs to the job queue if they can force a restart of the condor_schedd to which they submit jobs. The user has complete control of the job attributes, including the user and executable.

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 use of Condor queue management commands. The difficulty in exploiting this vulnerability is finding a sequence of actions that will cause the condor_schedd to restart.

high

Since the attacker can completely manipulate the attributes of jobs, they can cause jobs to be run as other users (other than root). Depending on the configuration, this may allow the attacker to gain access to data owned by another user, or system accounts. It could also be used for denial of service attacks or to destroy the integrity of existing jobs on the condor_schedd.

Condor keeps a disk-based log file of the condor_schedd job queue. The format of the job queue log is a set of records each terminated by a new line. Each record consists of three parts: a record type number, a job identifier, and data. A command line tool, condor_qedit, can be used to modify values of a user's job. This code does not check for the existence of new-line characters in the updated job attribute name or value, so a carefully crafted use of condor_qedit can be used to add arbitrary entries to the job queue log file. For instance, the following perl script will cause records to be injected into the queue:

  #!/usr/bin/perl

  system("condor_qedit",
         "1.0",
         "safe_attr_name",
         "safe_value\n103 2.0 injected_name injected_value"
        );
  

This will add the following to the job queue log file:

  105
  103 1.0 safe_attr_name safe_value
  103 2.0 injected_name injected_value
  106
  

The condor_schedd normally only uses an in-memory version of the data that does not have a problem with attribute names or values containing new-lines. Since the job queue log file is only used in the event of the condor_schedd restarting, the attacker must also get the condor_schedd to crash or restart.

failure to validate input
injection

The cause of this is failure to validate the names and values of the job attributes written into the job queue log file. Specifically, it does not check for new-lines within the attribute name or value. An alternative view of the cause would be the data format of the job queue log file not allowing all possible values that a user could supply.

There are two possible mitigations to this vulnerability. The first is to check job attribute names and values for a new-line character and to reject any job queue log file entry that contains a new-line character.

The second mitigation technique would be to make the job queue log file allow any characters in a record, by encoding and decoding new-line characters, or by having each entry's name and value also contain the length of the name and value.

This vulnerability was fixed by disallowing new-line characters in an attributes name or value.

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