Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 81344 - app-emulation/vmware-workstation: world writable directory in rpath and search path
Summary: app-emulation/vmware-workstation: world writable directory in rpath and searc...
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo Security
Whiteboard: B2 [glsa]
: 81462 (view as bug list)
Depends on:
Blocks: 81745
  Show dependency tree
Reported: 2005-02-09 04:03 UTC by Tavis Ormandy (RETIRED)
Modified: 2006-05-25 11:43 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Note You need to log in before you can comment on or make changes to this bug.
Description Tavis Ormandy (RETIRED) gentoo-dev 2005-02-09 04:03:28 UTC
$ chrpath --list /opt/vmware/lib/lib/ 
/opt/vmware/lib/lib/ RPATH=/tmp/rrdharan/out/lib

vmware-workstation provides it's own libraries to reduce runtime dependencies, should a user not have libgdk_pixbuf installed vmware will use it's own version, which includes an rpath in an world writable directory (/tmp/rrdharan/out/lib, presumably where a vmware employee compiled it).

The rpath should be removed for security reasons, as the vmware-workstation ebuild does not depend on libgdk_pixbuf if a user doesn't have them installed, a malicious user could create libraries there and get the vmware user to execute arbritrary code, (see bug 75181, comment #6 for an example).

Reproducible: Always
Steps to Reproduce:
Comment 1 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-09 04:28:05 UTC
So... to simplify all the rpath stuff, vmware-workstation should just RDEPEND on gdk-pixbuf, and we should remove the vmware-provided library via the ebuild, correct?
Comment 2 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-09 04:53:32 UTC
Chris: sure, that would solve it :)
Comment 3 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-09 05:14:01 UTC
Also, which vmware versions does this affect?  Is this still a problem with the vmware 5 betas/rc1?  If so, have you reported it upstream, so that they don't make the same mistake in vmware 5 final?
Comment 4 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-09 05:57:30 UTC
Chris: i've just checked 5.0_rc1, it's not it's only the 4.x versions :)
Comment 5 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-09 07:20:42 UTC
If this was only present in the libgdk_pixbuf stuff and not any of the other libraries, then it is resolved for vmware-workstation 3.x and 4.5
Comment 6 Dan Andresan 2005-02-09 19:39:56 UTC
Nice, so I've just emerged vmware-workstation-, upgrading from vmware-workstation-, and vmware doesn't work anymore.

I have an amd64.
dan@asgard:~> vmware
/opt/vmware/lib/bin/vmware: error while loading shared libraries: cannot open shared objectfile: No such file or directory

dan@asgard:~> locate

so, if i try to understand what's happening, i have libgdk_pixbuf for 64 bits.
vmware needs libgdk_pixbuf 32 bits, it comes with them "to reduce runtime dependencies", but you "remove[d] the vmware-provided library via the ebuild" to fix a security risk, and vmware cannot run anymore as it has no access to the libraries.

because vmware is now RDEPEND on gdk-pixbuf you thought it's safe to delete the vmare libs, but my gdk-pixbuf installation is not usable by vmware, since it's on 64 bits.

as a quick fix, you should delete the vmware libs only on x86, not on amd64. also, RDEPEND should be only for x86, as for amd64 it doesn't matter.

best wishes, Dan Laba.

Comment 7 Jesús García Crespo (aka Sevein) 2005-02-10 01:09:11 UTC
[ebuild  NS   ] sys-libs/db-1.85-r2  14 kB
[ebuild  N    ] media-sound/esound-0.2.34  +alsa -ipv6 +tcpd 310 kB
[ebuild  N    ] gnome-base/orbit-0.5.17  1,040 kB
[ebuild  N    ] gnome-base/gnome-libs-1.4.2  -doc -kde -nls 2,807 kB
[ebuild  N    ] media-libs/gdk-pixbuf-0.22.0-r3  -doc +mmx 388 kB
[ebuild     U ] app-emulation/vmware-workstation- [] 257 kB

gdk-pixbuf? I don't need it!
My vmwarek-workstation- worked very good without it, :(.
Comment 8 Carsten Lohrke (RETIRED) gentoo-dev 2005-02-10 04:07:27 UTC
*** Bug 81462 has been marked as a duplicate of this bug. ***
Comment 9 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-10 04:36:27 UTC
Fine... I'll just package.mask vmware-workstation until a proper solution is reached.
Comment 10 Konstantin Münning 2005-02-10 06:35:30 UTC
To Severin: you don't need it as you have the "old" version with own gdk-pixbuf.

To Chris: as there is only one vmware-workstation-4.x ebuild when you mask it then there will be none left. IMHO not that good solution. Maybe leave gdk-pixbuf for amd64 and print a warning about this bug here...
Comment 11 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-10 10:13:10 UTC
I will be testing a fix for this tonight when I get home (and access to my amd64) and will be unmasking the package once I have fixed it.
Comment 12 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-10 11:17:28 UTC

I stripped the rpath locally and made a tarball of the new libraries.  There is a new -r4 ebuild for vmware-workstation 4.5 that pulls in these files and removes the ones shipped with vmware.  This should work on both amd64 and x86.  I have also removed the package.mask that had been added for vmware-workstation.  This should now be resoved from the ebuild standpoint.
Comment 13 Bertrand CHERRIER 2005-02-10 15:25:16 UTC
The -r4 version improved a little bit, as now we can see the vmware window for about 1/4 of a second ... but it seems that there still is a problem with gdk-pixbux, next is what I get when I launch vmware :

** WARNING **: Unable to load module: Ne peut ouvrir le fichier d'objet partag
Comment 14 Bertrand CHERRIER 2005-02-10 15:25:16 UTC
The -r4 version improved a little bit, as now we can see the vmware window for about 1/4 of a second ... but it seems that there still is a problem with gdk-pixbux, next is what I get when I launch vmware :

** WARNING **: Unable to load module: Ne peut ouvrir le fichier d'objet partagé: Aucun fichier ou répertoire de ce type
** WARNING **: Can't find gdk-pixbuf module for parsing inline XPM data
** CRITICAL **: file gdk-pixbuf.c: line 331 (gdk_pixbuf_get_width): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf.c: line 347 (gdk_pixbuf_get_height): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf-render.c: line 349 (gdk_pixbuf_render_pixmap_and_mask): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf.c: line 299 (gdk_pixbuf_get_bits_per_sample): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf.c: line 283 (gdk_pixbuf_get_has_alpha): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf.c: line 251 (gdk_pixbuf_get_colorspace): assertion `pixbuf != NULL' failed.
** CRITICAL **: file gdk-pixbuf.c: line 170 (gdk_pixbuf_new): assertion `bits_per_sample == 8' failed.
** CRITICAL **: file gdk-pixbuf-util.c: line 114 (gdk_pixbuf_copy_area): assertion `src_pixbuf != NULL' failed.
Comment 15 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-10 15:51:33 UTC
Strange... it worked perfectly fine for me... the only difference in the libraries is the rpath has been removed.  Otherwise, they are identical to the vmware-provided ones.
Comment 16 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-10 16:07:32 UTC
There was a typo, I corrected it (hope that's okay), after that it works perfectly here, Thanks Chris :)

I've reported this upstream, as an example of exploitation (for future reference):

Make sure you havnt got gdk-pixbuf installed.

$ mkdir -p /tmp/rrdharan/out/lib/gdk-pixbuf/loaders/
$ gcc -shared rpath.c -o /tmp/rrdharan/out/lib/gdk-pixbuf/loaders/
$ vmware
exploit code now in control!

** WARNING **: gdk-pixbuf XPM module lacks XPM data capability

where rpath.c contains:

#include <stdio.h>

void __attribute__ ((constructor)) rpath_exploit (void);

void rpath_exploit (void)
        fprintf (stderr, "exploit code now in control!\n");
        /* insert evil code here */

as you can see /tmp is a world writable directory where anyone can drop code, which would be executed on running vmware.
Comment 17 Bertrand CHERRIER 2005-02-10 17:15:28 UTC
After doing an unmerge of gdk_pixbuf, unmerge vmware, emerge vmware I was still having the same problem.

Here is what I've done to make it work :

edit the ebuild, and comment the following lines :

rm -rf ${Ddir}/lib/lib/{png,xpm}.so.1.0.0

so the exploit is back in, but it's working ... 
I can do more test if you want me to, now that I know how to get it back online !
Comment 18 Bertrand CHERRIER 2005-02-10 17:17:16 UTC
oopss !
I meant 

edit the ebuild, and UNcomment the following lines :

Comment 19 Thierry Carrez (RETIRED) gentoo-dev 2005-02-11 07:33:26 UTC
Hmm... Bertrand's problem tend to prove that the fix is buggy... Anyone else reproducing the problem ?
Comment 20 Chris Gianelloni (RETIRED) gentoo-dev 2005-02-11 08:46:30 UTC
Try the -r5 ebuild, as it uses a different method (changing the rpath to a non-existent, non-writeable directory).  Blame taviso if it doesn't work... ;]
Comment 21 Tavis Ormandy (RETIRED) gentoo-dev 2005-02-11 09:15:18 UTC
I think Bertrand was seeing the typo I corrected

Chris: -r5 works fine here, and prevents the rpath and search path vulnerabilities :)

No response form upstream they say here they will create a "knowledge base article" as soon as they are informed (email was sent on the 9th), but I can't see one.
Comment 22 Bertrand CHERRIER 2005-02-11 17:49:59 UTC
It's working great now !
Thanks for everything
Comment 23 Thierry Carrez (RETIRED) gentoo-dev 2005-02-12 04:52:45 UTC
REady for GLSA
Comment 24 Thierry Carrez (RETIRED) gentoo-dev 2005-02-14 12:24:57 UTC
GLSA 200502-18, good work Tavis !
Comment 25 Chris Gianelloni (RETIRED) gentoo-dev 2006-05-23 13:30:04 UTC
This was fixed in he 3.x branch with vmware-workstation-, which isn't listed in the GLSA, causing a false positive in ferringb's vulnerabilities script.
Comment 26 Stefan Cornelius (RETIRED) gentoo-dev 2006-05-25 11:43:33 UTC
updated GLSA in cvs