Bug 848212 (CVE-2012-3490) - CVE-2012-3490 condor: does not check return value of setuid and similar calls, exploitable via VMware support
Summary: CVE-2012-3490 condor: does not check return value of setuid and similar calls...
Keywords:
Status: CLOSED NOTABUG
Alias: CVE-2012-3490
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 835595
Blocks: 828434 846654
TreeView+ depends on / blocked
 
Reported: 2012-08-14 22:24 UTC by Vincent Danen
Modified: 2019-09-29 12:54 UTC (History)
8 users (show)

Fixed In Version: condor 7.6.10, condor 7.8.4
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2012-09-19 21:06:26 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2012:1278 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Grid 2.2 security update 2012-09-19 21:40:26 UTC
Red Hat Product Errata RHSA-2012:1281 normal SHIPPED_LIVE Moderate: Red Hat Enterprise MRG Grid 2.2 security update 2012-09-19 21:51:29 UTC

Description Vincent Danen 2012-08-14 22:24:59 UTC
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 08:14:27 UTC
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 15:57:38 UTC
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 15:52:29 UTC
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 15:53:55 UTC
Acknowledgements:

This issue was discovered by Florian Weimer of the Red Hat Product Security Team.

Comment 7 errata-xmlrpc 2012-09-19 17:45:16 UTC
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 17:53:13 UTC
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 21:58:50 UTC
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 21:42:57 UTC
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.