Bug 848212 - (CVE-2012-3490) CVE-2012-3490 condor: does not check return value of setuid and similar calls, exploitable via VMware support
CVE-2012-3490 condor: does not check return value of setuid and similar calls...
Status: CLOSED NOTABUG
Product: Security Response
Classification: Other
Component: vulnerability (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Red Hat Product Security
impact=moderate,public=20120919,repor...
: Security
Depends On: 835595
Blocks: 828434 846654
  Show dependency treegraph
 
Reported: 2012-08-14 18:24 EDT by Vincent Danen
Modified: 2012-09-20 17:42 EDT (History)
8 users (show)

See Also:
Fixed In Version: condor 7.6.10, condor 7.8.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-19 17:06:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Vincent Danen 2012-08-14 18:24:59 EDT
Florian Weimer of the Red Hat Product Security Team reported that certain functions in Condor (my_popenv_impl and my_spawnv in src/condor_utils/my_popen.cpp) did not check the return value of setuid and similar function calls:

* euid = geteuid();
* egid = getegid();
* seteuid( 0 );
* setgroups( 1, &egid );
* setgid( egid );
* setuid( euid );

As a result, the subprocess could possibly be created with root privileges instead of those of the intended user.
Comment 3 Florian Weimer 2012-08-21 04:14:27 EDT
Sorry, I had missed your question.  See my last comment on the original bug:

I tried to come up with a scenario in which a UID transition does actually occur, and failed.  I don't think anymore this is a security issue.  One of the callers, privsep_popen, is dead code.  The other paths do not specify a UID change, so the code just tries to adjust the effective user/group IDs.  This does not appear to be necessary for the my_popen(v) call sites in the code base.
Comment 4 Vincent Danen 2012-09-15 11:57:38 EDT
Upon further review, it looks as though the only exploitable issue here is this:

No checks in ./src/condor_vm-gahp/vmgahp_common.cpp between lines 659 and 662:
            seteuid( 0 );
            setgroups( 1, &egid );
            setgid( egid );
            setuid( euid );

This code is present in the VMware support, which has been confirmed to not be active in our packages, so the relevant code path cannot be triggered.  Our packages use the Xen part only, and that invokes systemCommand with PRIV_ROOT anyways, so there is no privilege escalation to be had.
Comment 5 Vincent Danen 2012-09-19 11:52:29 EDT
Statement:

Not vulnerable.  This issue did not affect the versions of condor as shipped with Red Hat Enterprise MRG as it does not include the vulnerable code (VMware support is not compiled in).
Comment 6 Vincent Danen 2012-09-19 11:53:55 EDT
Acknowledgements:

This issue was discovered by Florian Weimer of the Red Hat Product Security Team.
Comment 7 errata-xmlrpc 2012-09-19 13:45:16 EDT
This issue has been addressed in following products:

  MRG for RHEL-5 v. 2

Via RHSA-2012:1278 https://rhn.redhat.com/errata/RHSA-2012-1278.html
Comment 8 errata-xmlrpc 2012-09-19 13:53:13 EDT
This issue has been addressed in following products:

  MRG for RHEL-6 v.2

Via RHSA-2012:1281 https://rhn.redhat.com/errata/RHSA-2012-1281.html
Comment 9 Vincent Danen 2012-09-19 17:58:50 EDT
This has been resolved in upstream 7.6.10 and 7.8.4:

https://lists.cs.wisc.edu/archive/condor-users/2012-September/msg00077.shtml
Comment 10 Vincent Danen 2012-09-20 17:42:57 EDT
Git commit for this fix:

http://condor-git.cs.wisc.edu/?p=condor.git;a=commitdiff;h=94e84ce4

Note You need to log in before you can comment on or make changes to this bug.