CONDOR-2005-0004

Arbitrary configuration options can be set if a user has access to the "condor" user account that Condor components run as, even if all the configuration files are owned by root. This can lead to a denial of service, or a complete root compromise of the system if the condor_master is started as root.

local Condor user

This vulnerability requires local access on a machine as the user that Condor components use in their non-privileged state.

medium

To exploit this vulnerability requires only access as the condor uid on a host which runs any Condor component. Once this access is gained the rest is relatively simple.

high

Since this vulnerability can affect the configuration of all Condor components running on a machine, it can have consequences ranging from changing the matching criteria of jobs (to only allow matches from a particular user), to denial of service (by not starting components), to full root access.

If Condor is configured to start as root, condor_master is started on the machine as root, and it takes care of starting the appropriate Condor components as defined in the configuration files. It starts these as root and the individual components then change their effective id to the condor uid for most of their operation and other uids as needed. Since the components to start and the paths to the components are in the configuration, these can be changed to start a new malicious daemon, or to change the path of an existing daemon to a malicious one, which can then exec the real daemon to hide the fact that it was run. Since all daemons are started as root, the malicious ones will be also be run with the root uid.

In order to allow runtime configuration changes which are persistent between restarts of Condor components, changes to the configuration for a component are stored in hidden files in the Condor log directory. This directory and the files written are owned by the condor user.

Condor has a set of configuration attributes (see SETTABLE_ATTRS) to restrict what setting can be changed for what components, and by whom, but these are only checked when an attempt is made to change the setting using the condor_config_val program by the targeted component.

When condor_config_val is used to change an attribute ($ATTR, $UATTR is the same as $ATTR in all uppercase) to a value ($VALUE) of the component ($COMP which is all uppercase without the condor_ prefix), two files are modified or created in the Condor log directory ($LOG):

$LOG/.config.$COMP:

RUNTIME_CONFIG_ADMIN = $ATTR [, $ATTRn]...

$LOG/.config.$COMP.$ATTR:

$UATTR = $VALUE

For instance, if you had access to the condor account on a machine that a condor_schedd ran on, you could add the following two files:

$LOG/.config.MASTER:

RUNTIME_CONFIG_ADMIN = schedd

$LOG/.config.MASTER.schedd:

SCHEDD = malicious_program_path

You would then need to get the condor component (condor_schedd) to restart on this machine. This could be accomplished by killing the component and having the condor_master restart things automatically, rebooting the system, or using the condor_reconfig which is supposed to reread the configuration files (including the ones in the $(LOG) directory) and reconfigure and restart things as appropriate (this does not work in the current example due to a bug in the condor_master).

failure to validate input
insecure permissions

The cause of this is a failure to validate the values held in these configuration files against permissible values (this is only done when setting values using the condor_config_val program). It is also caused by these files being stored with permissions and ownership such that the condor uid can update and create these files. They should only be allowed to be created and modified by the root uid.

In a configuration where condor_master and other components are started as root and the configuration files determine what executables are run, all configuration files need to be owned by root. Otherwise having access to the condor uid is the same as having access to the root uid. Several things should be done to prevent this vulnerability.

First, a union of all the configuration attributes of the form [SUBSYS_]SETTABLE_ATTRS_PERMISSION-LEVEL should be made and only the attributes in the union should be allowed to be set. A good practice would be to only allow settings which do not affect which external programs are executed, what uids are used, and any other setting which may compromise security.

Second, the owner of the runtime configuration files should be root and should have permissions that only allow root to update these files. This can be accomplished in one of two ways. The files could be placed in a separate directory whose ancestors are all owned by root to prevent deletion and replacement of the file, with a check to verify this on every access. Another solution would be to write the files in the log directory as they are now, but to write the files with a owner of root and with sufficient privileges so that only root can update them. Then after the file is opened, but before it is processed, an fstat could be done on the file descriptor to determine the owner and privileges to verify that only root could change the file. If they are valid then process the file, otherwise do not process the file.

If a mechanism already exists for distributing configuration files or they are placed in a shared file system, it would be best to disable all but user defined attributes on a host, and to use the distribution method to change system configuration options.

Lastly, these configuration files should be shown the light of day by documenting them, not hiding them in the file system (by not starting their names with a dot and putting them all in their own subdirectory), and listing them when using the condor_config_val command with the -v option.

The persistent configuration files that are written by the daemons when set through condor_config_val are now checked to verify that they are owned by the real user of the condor daemon (root or the "condor" user).

Also, the feature to allow dynamic and persistent configuration changes through condor_config_val is now controlled by three new configuration options: ENABLE_RUNTIME_CONFIG, ENABLE_PERSISTENT_CONFIG and PERSISTENT_CONFIG_DIR. The configuration options ENABLE_RUNTIME_CONFIG and ENABLE_PERSISTENT_CONFIG default to disabled. If they are both enabled, the path in PERSISTENT_CONFIG_DIR is used as the directory to contain the files.

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