Bug 544371 (CVE-2009-4133)

Summary: CVE-2009-4133 Condor: queue super user cannot drop privs
Product: [Other] Security Response Reporter: Matthew Farrellee <matt>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact: Martin Kudlej <mkudlej>
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jlieskov, jneedle, mjc, mkudlej, security-response-team, vdanen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
URL: http://condor-wiki.cs.wisc.edu/index.cgi/tktview?tn=1018
Whiteboard:
Fixed In Version: condor 7.4.1-0.7.1 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-04-24 03:52:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 545352, 545944, 549577    
Bug Blocks:    

Description Matthew Farrellee 2009-12-04 18:35:06 UTC
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 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, 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

Comment 6 Mark J. Cox 2009-12-08 09:44:54 UTC
We've assigned this CVE-2009-4133.  Matt, please can you give this name to upstream for them to reference in their future fix/announcements.

Comment 16 Vincent Danen 2009-12-16 21:11:51 UTC
A flaw was found in the way Condor manages jobs.  This flaw could allow
a user that was already authorized to submit jobs into Condor, to queue
a job under the guise of a different local user, potentially leading to 
unauthorized access of that account. (CVE-2009-4133)

Note: Condor will not run jobs as root; therefore, this flaw cannot lead to a compromise of the root user account.

Comment 18 Vincent Danen 2009-12-22 01:20:27 UTC
7.4.1 has been released to address this issue:

http://www.cs.wisc.edu/condor/manual/v7.4/8_3Stable_Release.html#SECTION00931000000000000000

Comment 19 errata-xmlrpc 2009-12-22 01:25:00 UTC
This issue has been addressed in following products:

  Grid for MRG on RHEL-4
  Grid Execute Node for MRG on RHEL-4

Via RHSA-2009:1688 https://rhn.redhat.com/errata/RHSA-2009-1688.html

Comment 20 errata-xmlrpc 2009-12-22 01:28:18 UTC
This issue has been addressed in following products:

  MRG for RHEL-5

Via RHSA-2009:1689 https://rhn.redhat.com/errata/RHSA-2009-1689.html

Comment 22 Fedora Update System 2010-01-07 00:54:40 UTC
condor-7.4.1-1.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 23 Fedora Update System 2010-01-07 00:56:04 UTC
condor-7.4.1-1.fc11 has been pushed to the Fedora 11 stable repository.  If problems still persist, please make note of it in this bug report.