Bug 474285 (CVE-2009-1142)

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.

/*
 * 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.
 */

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.

I will just close it. If you think differently please speak up and reopen. :)

Thomas: is it OK to pass the audit results to upstream so they can fix it ? (the same for bug#372070)

(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.

> 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 / 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.

CVE-2009-1142

Pavol,
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.

~> 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.

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.

(In reply to comment #12)
> thoimas, can we accept it like this?

"Yes we can!" :)

Pavol,
I do not know if something more is needed... just close this bug, when you are done. Thanks.

Dominique?

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).

ok!

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.

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.

This is an autogenerated message for OBS integration:
This bug (474285) was mentioned in
https://build.opensuse.org/request/show/89843 Tumbleweed / permissions