CVE-2009-4133: Medium severity htcondor vulnerability

http://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=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.

The problem with this is that condorshadow authenticates to the schedd as the condor user (always a super user) when performing setjobattr 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, and it can not gain access to root, because condor will not run jobs as root.

The solution we decided to pursue in 7.2.5 and 7.4.1 is 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.

2009-Dec-03 10:18:58 by danb: The problem is slightly worse than we previously thought. Even before 7.2.0 chirp can set the owner to the condor user. This is possible because in all existing versions of condor, any user is allowed to set Owner to the authenticated name of the qmgmt connection, and the shadow authenticates as the condor user.

So in all versions of condor that support chirp's set attribute operation (appears to be 6.5.4+), it is possible to become the condor user. In 7.2.0+, it is also possible to become other users who have previously submitted jobs. Since the condor user is always the queue super user (regardless of configuration), becoming the condor user gives one power to modify all other jobs in the queue, effectively allowing one to become those users as well. Therefore, the only additional exposure added in 7.2.0+ is the ability to become users who no longer have jobs in the queue but who submitted jobs to this schedd in the past (since the schedd was last started).

Version-Release number of selected component (if applicable):

All condor including 7.4.1-0.7

— Red Hat