Bug 474285 (CVE-2009-1142)

Summary: AUDIT-0: CVE-2009-1142: open-vm-tools: suid binary
Product: [Novell Products] SUSE Security Incidents Reporter: Pavol Rusnak <prusnak>
Component: IncidentsAssignee: Dominique Leuenberger <dimstar>
Status: RESOLVED FIXED QA Contact: Security Team bot <security-team>
Severity: Normal    
Priority: P5 - None CC: dimstar, meissner, security-team
Version: unspecified   
Target Milestone: ---   
Hardware: Other   
OS: Other   
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description Pavol Rusnak 2009-02-10 11:35:07 UTC
New version of open-vm-tools ship with binary /usr/bin/vmware-user-suid-wrapper which needs to have suid bit enabled. The sources are in vmware-user-suid-wrapper directory. Would you be so kind and do a review of the sources, because I want to put the new version in Factory - the updated package is in Virtualization:VMware BuildService project ATM. Thanks!
Comment 1 Ludwig Nussel 2009-02-10 11:43:20 UTC
vmware is a proprietary 3rd party product we don't ship. So why should we need a setuid bit for vmware tool by default?

Anyways, just go ahead and submit your package with all preparations (%verifyscript etc) but without the actual setuid bit to Factory.
Comment 2 Thomas Biege 2009-03-19 09:37:01 UTC
 * main.c --
 *      This program is run as root to prepare the system for vmware-user.  It
 *      unmounts the vmblock file system, unloads the vmblock module, then
 *      reloads the module, mounts the file system, and opens a file descriptor
 *      that vmware-user can use to add and remove blocks.  This must all
 *      happen as root since we cannot allow any random process to add and
 *      remove blocks in the blocking file system.
Comment 3 Thomas Biege 2009-03-19 11:53:48 UTC
Calling function ChmodChownDirectory() (depends on TOGGLE_VMBLOCK) in a setuid root process will cause trouble (NOTE: untested).
- path is a #define
- path points to /tmp/
- open(path, O_RDONLY) follows links
- local user can create dir like TMP_DIR in /tmp/ as link to
  another directory not owned by him
- fchown(fd, uid, gid) will change the ownership of this arbitrary dir to root
- fchmod(fd, mode) will also change mode to 777 
- This does not work if path is already owned by root.

Therefore NO setuid root bit.
Comment 4 Thomas Biege 2009-03-19 12:05:07 UTC
I will just close it. If you think differently please speak up and reopen. :)
Comment 5 Pavol Rusnak 2009-03-19 13:53:28 UTC
Thomas: is it OK to pass the audit results to upstream so they can fix it ? (the same for bug#372070)
Comment 6 Thomas Biege 2009-03-19 14:01:58 UTC
(In reply to comment #5)
> Thomas: is it OK to pass the audit results to upstream so they can fix it ?
> (the same for bug#372070)

Yes, lets get in contact with them.

I informed the other vendors about this possible bugs and we should _not_ make it public as long as we don't know one of them is affected.
Comment 7 Thomas Biege 2009-03-19 14:05:33 UTC
> I informed the other vendors about this possible bugs and we should _not_ make
> it public as long as we don't know one of them is affected.

Not sure if this sentence makes any sense. ;) So let me paraphrase: Let's wait for other vendor's response before we make it public; often a coordinated release date will be negotiated.
Comment 8 Dominique Leuenberger 2009-03-20 08:25:23 UTC
comment / reply by Dmitry Torokhov @ VMware:
>TOGGLE_VMBLOCK is only defined on FreeBSD and Solaris (and there we should
>be moving away from using it) so I don't think there is an issue with
>vmware-user-suid-wrapper to have suid bit.
Comment 9 Thomas Biege 2009-03-26 07:24:19 UTC
Comment 10 Thomas Biege 2009-03-26 07:41:59 UTC
please verify if TOGGLE_VMBLOCK is defined during our autobuild process. If not, you can set it setuid root. Otherwise we need an update/patch.
Comment 11 Dominique Leuenberger 2009-03-26 07:48:01 UTC
~> osc buildlog openSUSE_Factory x86_64 | grep TOGGLE_VMBLOCK
~> osc buildlog openSUSE_Factory i586 | grep TOGGLE_VMBLOCK

Neither of the commands gives an output, hinting that neither i586 nor x86_64 ever pass this define to the compiler.
Comment 12 Marcus Meissner 2009-08-03 15:01:36 UTC
thoimas, can we accept it like this?

the setuid handling needs to be different. I suspect we do not want the setuid bit in paranoid and secure mode, and so the .spec file also needs to be adjusted to use the correct %verify patterns etc.
Comment 13 Thomas Biege 2009-08-03 17:39:26 UTC
(In reply to comment #12)
> thoimas, can we accept it like this?

"Yes we can!" :)
Comment 14 Thomas Biege 2009-08-06 06:05:52 UTC
I do not know if something more is needed... just close this bug, when you are done. Thanks.
Comment 15 Pavol Rusnak 2009-08-06 07:15:05 UTC
Comment 16 Dominique Leuenberger 2009-08-06 07:21:17 UTC
I'd say to keep it here until at least SR 15467 has been accepted into oS:F (which is hopefully going to happen soon).
Comment 17 Thomas Biege 2009-08-06 09:42:39 UTC
Comment 18 Marcus Meissner 2009-08-06 15:08:39 UTC
I am giving it 4755 for that binary in .easy mode

.secure and .paranoid have it marked as 0755.

I have adjusted and cleaned up your .spec file and submitreq

If you use the package for older distros it might need some adjustments, but
this is the factory spec file.
Comment 19 Dominique Leuenberger 2009-08-10 08:17:07 UTC
I think it's all done from here what we can. Even though I'm fighting to get the package accepted now.... but that's out of the scope of this ticket.
Comment 20 Bernhard Wiedemann 2011-10-31 21:01:52 UTC
This is an autogenerated message for OBS integration:
This bug (474285) was mentioned in
https://build.opensuse.org/request/show/89843 Tumbleweed / permissions