Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

Current stable vmware comes with it's own libssl.so.0.9.7, so CVE-2006-4339

Current stable vmware comes with it's own libssl.so.0.9.7, so CVE-2006-4339¹
might apply here as well.


[1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4339

vmware please advise.

I'll have time to look into this on monday... but it'll be more than just
workstation, likely.

Chris, did you have time to look into this?

I have no idea if the openssl shipped with vmware-workstation and vmware-player
is vulnerable, but the application will work without the shipped libraries, as
far as my testing has shown.  I'll get to an ebuild for 4.5.3 and 5.5.1/5.5.2
tomorrow.

Chances are vmware-server's going to work in exactly the same way, so please
leave the bug open after you get your ebuilds changed Chris, and I'll pull the
changes across to server...

Mike: actually, if you can test that vmware-server still works (specifically
the SSL parts) after removing /opt/vmware/server/lib/lib/libssl* then I can
make the change in the eclass instead and we can simply revision bump to force
an upgrade.

Ok, I removed both /opt/vmware/server{,/console}/lib/lib/libssl-0.9.7/* and
vmware all starts up ok, my virtual machine connects, and the console doesn't
offer any problems connecting to the server (which is all done through SSL), so
both the console and the server appear fine without their native ssl libs.  I
have the feeling we'll get maybe one unusual setup that files a bug, but
otherwise I think we're good to put it in the ebuild.  Thanks Chris!  5:)

The following need to be marked stable:

app-emulation/vmware-player-1.0.1.19317-r5 (amd64, x86)
app-emulation/vmware-workstation-3.2.1.2242-r12 (x86)
app-emulation/vmware-workstation-4.5.3.19414-r5 (amd64, x86)
app-emulation/vmware-workstation-5.5.1.19175-r5 (amd64, x86)

Mike has updated the vmware-server stuff, but it wasn't stable to begin with,
so it shouldn't affect GLSA.  Also, vmware-{esx,gsx}-console needs to be done,
but they aren't stable on any arches, either.

Thx Chris.

Arches please test and mark stable.

Created an attachment (id=98382) [details]
ui-9725.log

# grep libssl /usr/portage/eclass/vmware.eclass
        # We remove the shipped libssl for bug #148682
        rm -rf "${S}"/lib/lib/libssl-0.9.*

If I understand this fix correctly the above should have been:

# grep libssl /usr/portage/eclass/vmware.eclass  | \
    sed -e 's/libssl-/libssl.so./'
        # We remove the shipped libssl for bug #148682
        rm -rf "${S}"/lib/lib/libssl.so.0.9.*

After correcting it into that, however,
app-emulation/vmware-workstation-5.5.1.19175-r5 does NOT work for me (note that
the libpng issue is unrelated/was present before this):

$ vmware
/opt/vmware/workstation/lib/bin/vmware:
/opt/vmware/workstation/lib/lib/libpng12.so.0/libpng12.so.0: no version
information available (required by /usr/lib/libcairo.so.2)
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory


VMware Workstation Error:
VMware Workstation unrecoverable error: (vmui)
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory
A log file is available in "/tmp/vmware-bo/ui-8225.log".  Please request
support and include the contents of the log file.
To collect files to submit to VMware support, run vm-support.
We will respond on the basis of your support entitlement.


Press "Enter" to continue...
/opt/vmware/workstation/lib/bin/vmware:
/opt/vmware/workstation/lib/lib/libpng12.so.0/libpng12.so.0: no version
information available (required by /usr/lib/libcairo.so.2)
/opt/vmware/workstation/lib/bin/vmware:
/opt/vmware/workstation/lib/lib/libpng12.so.0/libpng12.so.0: no version
information available (required by /usr/lib/libcairo.so.2)
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory


VMware Workstation Error:
VMware Workstation unrecoverable error: (vmui)
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory
A log file is available in "/tmp/vmware-bo/ui-9725.log".  Please request
support and include the contents of the log file.
To collect files to submit to VMware support, run vm-support.
We will respond on the basis of your support entitlement.


Press "Enter" to continue...

Gentoo Base System version 1.12.5
Portage 2.1.1 (default-linux/x86/2006.1/desktop, gcc-4.1.1, glibc-2.4-r3,
2.6.17-suspend2-r5 i686)
=================================================================
System uname: 2.6.17-suspend2-r5 i686 Intel(R) Pentium(R) M processor 1600MHz
Last Sync: Thu, 28 Sep 2006 23:30:01 +0000
ccache version 2.3 [enabled]
app-admin/eselect-compiler: [Not Present]
dev-java/java-config: 1.3.7, 2.0.30
dev-lang/python:     2.4.3-r4
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     2.3
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.17
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.16.1-r3
sys-devel/gcc-config: 1.3.13-r3
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17-r1
ACCEPT_KEYWORDS="x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=pentium-m -Os -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config
/usr/kde/3.5/shutdown /usr/share/X11/xkb /usr/share/config
/usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/
/usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/
/usr/share/texmf/xdvi/"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/gconf
/etc/java-config/vms/ /etc/revdep-rebuild /etc/splash /etc/terminfo"
CXXFLAGS="-march=pentium-m -Os -pipe"
DISTDIR="/opt/distfiles"
FEATURES="autoconfig buildpkg ccache collision-protect distlocks fixpackages
metadata-transfer parallel-fetch sandbox sfperms splitdebug strict test
userfetch"
GENTOO_MIRRORS="http://mirror.uni-c.dk/pub/gentoo
http://ftp.belnet.be/mirror/rsync.gentoo.org/gentoo"
LC_ALL="en_GB.utf8"
LINGUAS="da en en_GB"
MAKEOPTS="-j2"
PKGDIR="/opt/packages"
PORTAGE_RSYNC_EXTRA_OPTS="--timeout=60"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage"
SYNC="rsync://zlin.dk/gentoo-portage"
USE="x86 X aac acpi alsa asf bash-completion berkdb bitmap-fonts bluetooth
bzip2 cairo cdr cli crypt css cups dlloader dri dvd dvdr elibc_glibc emboss
encode fam fat fbcon ffmpeg firefox flac fortran gdbm gif gphoto2 gpm i8x0
ieee1394 imagemagick input_devices_evdev input_devices_keyboard
input_devices_mouse input_devices_synaptics input_devices_void irda irmc
isdnlog jfs jpeg kde kdehiddenvisibility kernel_linux lcd libg++ linguas_da
linguas_en linguas_en_GB logitech-mouse mad mikmod mmx mmxext mp3 mpeg mplayer
msn ncurses nls nptl nptlonly nsplugin ntfs ogg opengl pam pcre pdf perl png
ppds pppd python qt3 quicktime readline real reflection reiser4 reiserfs
scanner sdl session slp spell spl sse sse2 ssl subversion svg svga syslog tcpd
test tetex tiff truetype truetype-fonts type1-fonts udev unicode usb
userland_GNU vcd video_cards_fbdev video_cards_fglrx video_cards_i810
video_cards_radeon video_cards_vesa vim vorbis wifi win32codecs xcomposite xfs
xine xml xorg xscreensaver xv xvid zlib"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LDFLAGS

GRR...

What if you also remove libcrypto?  I am unable to get a failure here, even
duplicating exactly what you have done.

Created an attachment (id=98386) [details]
libcrypto removed too

(In reply to comment #11)
> GRR...
> 
> What if you also remove libcrypto?  I am unable to get a failure here, even
> duplicating exactly what you have done.

Then it complains about libcrypto instead.. :-/

When upgrading from openssl-0.9.7x to 0.9.8x the postinst give these
instructions:
# revdep-rebuild --library libssl.so.0.9.7
# revdep-rebuild --library libcrypto.so.0.9.7
After this, you can delete /usr/lib/libssl.so.0.9.7
and /usr/lib/libcrypto.so.0.9.7

Since I did that I can't run vmware with 0.9.8 only. Since wolf31o2 didn't do
that he still has the 0.9.7 libs and hence it works for him.

So in short: vmware requires 0.9.7 version of libcrypto and libssl.

Btw the libpng.so.12 issue went away by removing libpng12.so.0 also. Of course
that adds a dependency on ~media-libs/libpng-1.2.12..

Running vmware with VMWARE_USE_SHIPPED_GTK="force" fails with the following
error.

# VMWARE_USE_SHIPPED_GTK="force" vmware
ERROR: ld.so: object
'/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object
'/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object
'/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
LD_PRELOAD cannot be preloaded: ignored.
ERROR: ld.so: object
'/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
LD_PRELOAD cannot be preloaded: ignored.
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory


VMware Workstation Error:
VMware Workstation unrecoverable error: (vmui)
SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
cannot open shared object file: No such file or directory
A log file is available in "/tmp/vmware-creatix/ui-13319.log".  Please request
support and include the contents of the log file.
To collect files to submit to VMware support, run vm-support.
We will respond on the basis of your support entitlement.



The solution is to disable the lines 
#   vm_append_lib 'libcrypto.so.0.9.7'
#   vm_append_lib 'libssl.so.0.9.7'
in /opt/vmware/workstation/lib/lib/wrapper-gtk24.sh.

Note that I have /usr/lib/libssl.so.0.9.7 on my system.
BTW, I am using VMWARE_USE_SHIPPED_GTK="force" because of bug #128527

(In reply to comment #15)
> Running vmware with VMWARE_USE_SHIPPED_GTK="force" fails with the following
> error.
> 
> # VMWARE_USE_SHIPPED_GTK="force" vmware
> ERROR: ld.so: object
> '/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
> LD_PRELOAD cannot be preloaded: ignored.
> ERROR: ld.so: object
> '/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
> LD_PRELOAD cannot be preloaded: ignored.
> ERROR: ld.so: object
> '/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
> LD_PRELOAD cannot be preloaded: ignored.
> ERROR: ld.so: object
> '/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7' from
> LD_PRELOAD cannot be preloaded: ignored.
> SSLLoadSharedLibrary: Failed to load library
> /opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
> cannot open shared object file: No such file or directory
> 
> 
> VMware Workstation Error:
> VMware Workstation unrecoverable error: (vmui)
> SSLLoadSharedLibrary: Failed to load library
> /opt/vmware/workstation/lib/bin/libssl.so.0.9.7:/opt/vmware/workstation/lib/bin/libssl.so.0.9.7:
> cannot open shared object file: No such file or directory
> A log file is available in "/tmp/vmware-creatix/ui-13319.log".  Please request
> support and include the contents of the log file.
> To collect files to submit to VMware support, run vm-support.
> We will respond on the basis of your support entitlement.
> 
> 
> 
> The solution is to disable the lines 
> #   vm_append_lib 'libcrypto.so.0.9.7'
> #   vm_append_lib 'libssl.so.0.9.7'
> in /opt/vmware/workstation/lib/lib/wrapper-gtk24.sh.
> 
> Note that I have /usr/lib/libssl.so.0.9.7 on my system.
> BTW, I am using VMWARE_USE_SHIPPED_GTK="force" because of bug #128527
> 


I tried this, but since I'm running ~x86, I no longer have openssl-0.9.7.  It's
been upgraded to 0.9.8.  So, I take it vmware won't work for me now unless I
downgrade?

My apologies... I didn't read all the comments before posting my message.  It
seems my issue is exactly the same as described in comment #13.

*** Bug 149702 has been marked as a duplicate of this bug. ***

Looks like vmware are aiming for compatability by targetting the lowest current
openssl api and saying that it'd possible for 0.9.8 users to co-install a lower
version, whereas it'd be much more difficult for 0.9.7 users to do that[1].

Unfortunately, that means our best chance of getting a fix from vmware is for
them to push out patched version of their shipped libraries.  Ideally we need a
vmware contact since we're a rather large linux distribution who are often the
first to run into problems.  But so far, none of the vmware people we've
contacted have given us a response.

The only other solution for this that I can think of is to do some kind of
horrible slotted thing (since the openssl-0.9.7 binary still exists on my
system but hasn't been updated since I moved to 0.9.8).  At least that way both
versions would exist, but then the openssl maintainers would also have to keep
both patched and up-to-date.  I'm also not sure how packages would choose which
to link to.

Any other suggestions?  It's been mentioned that we patch it ourselves and
provide a precompiled version overwriting the base version, but that's not a
good long-term solution.  Any other suggestions?

[1] http://www.vmware.com/community/message.jspa?messageID=444548#444548

(In reply to comment #19)
> Looks like vmware are aiming for compatability by targetting the lowest current
> openssl api and saying that it'd possible for 0.9.8 users to co-install a lower
> version, whereas it'd be much more difficult for 0.9.7 users to do that[1].
> 
> Unfortunately, that means our best chance of getting a fix from vmware is for
> them to push out patched version of their shipped libraries.  Ideally we need a
> vmware contact since we're a rather large linux distribution who are often the
> first to run into problems.  But so far, none of the vmware people we've
> contacted have given us a response.
> 
> The only other solution for this that I can think of is to do some kind of
> horrible slotted thing (since the openssl-0.9.7 binary still exists on my
> system but hasn't been updated since I moved to 0.9.8).  At least that way both
> versions would exist, but then the openssl maintainers would also have to keep
> both patched and up-to-date.  I'm also not sure how packages would choose which
> to link to.
> 
> Any other suggestions?  It's been mentioned that we patch it ourselves and
> provide a precompiled version overwriting the base version, but that's not a
> good long-term solution.  Any other suggestions?
> 
> [1] http://www.vmware.com/community/message.jspa?messageID=444548#444548
> 

The messy workaround that worked for me was to emerge the latest openssl-0.9.7,
then re-emerge the latest 0.9.8.  I guess every time I notice an 0.9.7 update,
I could do this again, but security is not that critical for me.

(In reply to comment #19)
> The only other solution for this that I can think of is to do some kind of
> horrible slotted thing (since the openssl-0.9.7 binary still exists on my
> system but hasn't been updated since I moved to 0.9.8).  At least that way
> both versions would exist, but then the openssl maintainers would also have to
> keep both patched and up-to-date.

They already do that as can be seen in bug #145510.

> It's been mentioned that we patch it ourselves and provide a precompiled
> version overwriting the base version, but that's not a good long-term
> solution.

I don't see how that is any worse than waiting for vmware to do the exact same
thing. Just compile openssl-0.9.7l once and distribute lib{crypto,sll}.so.0.9.7
precompiled with vmware.

Chris: I don't think it is a good idea to rely on the system libs, as either
it'd mean to limit our library updates to VMWare's release cycle or to accept
to break VMWare every now and then.

At least VMWare Workstation is usually used on site (and you can log in
remotely using an independent ssh client/server combination, if necessary), so
I suppose this isn't a big issue, but on the other hand I don't know what the
openssl lib is actually used for.

Nevertheless, this is something to contact VMWare about, instead trying work
around the siuation, imho.

This issue also affects vmware-server which uses SSL to make the connection
between the console and the server.  Being able to intercept and/or manipulate
that is definitely a security issue.  Otherwise it's not clear what SSL'd be
used for, perhaps for data hashing or license verification?

*** Bug 149726 has been marked as a duplicate of this bug. ***

Just a note, this has now broken vmware-server for anyone who does not have a
system version of 0.9.7.  In my previous test, I assumed that all 0.9.8 ebuilds
would clean up after themselves, but I too had old 0.9.7 libraries lying
around.
Admittedly vmware-server is only ~ARCH, but a reliable workaround until vmware
can provide a new binary would be appreciated, even if it is not the best long
term solution...

(In reply to comment #25)
> Just a note, this has now broken vmware-server for anyone who does not have a
> system version of 0.9.7.  In my previous test, I assumed that all 0.9.8 builds
> would clean up after themselves, but I too had old 0.9.7 libraries lying
> around.
> Admittedly vmware-server is only ~ARCH, but a reliable workaround until vmware
> can provide a new binary would be appreciated, even if it is not the best long
> term solution...

It has broken vmware-workstation (including the stable version) also since
vmware.eclass deletes the affected libssl.so.0.9.7 that is distributed with
vmware. The bump was only to make sure everyone got the fix which unfortunately
only works if you have libssl from openssl-0.9.7l lying on the system..

I have confirmed that this is the case.  I downloaded the original tarball from
vmware (www.vmware.com), unpacked it, and copied in the lib/lib/libssl.0.9.7/*
directory from the tarball into /opt/vmware/lib/lib/ after the usual emerge.

This works as a workaround for the moment.  

Appreciate that this is insecure, but it is locked down to my local network
anyway.

*sigh*

I really, really hate this stuff sometimes.

Here's my plan:

- Grab an updated openssl-0.9.7l and throw it into a tarball on the mirrors
- leave vmware.eclass alone wrt removing vmware's libs
- add in code to copy our own libs in, instead
- looks like we'll need *another* revision bump of everything, which stinks

I have tried contacting VMware a few times.  I have never met with any success.
 We cannot rely on VMware for any kind of support, including security.  Waiting
for VMware is out of the question, so we'll do the work ourselves.

OK...

I've fixed everything now.  We need the following stable on amd64/x86.

vmware-workstation-4.5.3.19414-r6
vmware-workstation-5.5.1.19175-r6
vmware-player-1.0.1.19317-r5

We do not need to worry about vmware-workstation-3.x since it didn't ship its
own libssl.  It *may* statically link against libssl, but I'm marking it for
removal in 30 days anyway due to its age.

Of coure, vmware-server will need to be updated, too, but since there's no
stable versions of the ebuild, it isn't necessary for the GLSA.

Tested vmware-workstation-5.5.1.19175-r6.

QA Notice: you should let portage compress 'man1/vmware.1' for you
cp: cannot stat
`/var/tmp/portage/vmware-workstation-5.5.1.19175-r6/work/vmware-distrib/libssl.so.0.9.7':
No such file or directory

You seem to have forgotten to unpack vmware-libssl.so.0.9.7l.tar.bz2.

Sorry about that... I had forgotten to copy the new eclass correctly.  It's
good now, I just updated CVS, so it should hit the mirrors in 1+ hours.

Oh, dear:

# vmware
/opt/vmware/workstation/lib/bin/vmware: symbol lookup error:
/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7: undefined
symbol: EVP_idea_cbc
/opt/vmware/workstation/lib/bin/vmware: symbol lookup error:
/opt/vmware/workstation/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7: undefined
symbol: EVP_idea_cbc
#

Apparently it requires that libcrypto.so.0.9.7 is pulled from openssl-0.9.7l
too...

Doh, and I was just about to say vmware-server{,-console} had been bumped with
the new libssl fix...

I so need to figure out why everything is working perfectly for me locally.

Anyway, I'll update in just a moment.  I'm really sorry about all this.  I'm
testing this stuff locally and not having any issues, at all.

OK.  I updated the ebuilds (again) to -r7 for vmware-workstation and
vmware-player.  They're masked in package.mask because I'm sick of revision
bumping these things and prefer to know that it'll work before I bump it again.

Please test and report back.  As I said, I cannot duplicate this locally.

Finally I see no issues related to openssl.

app-emulation/vmware-workstation-5.5.1.19175-r7:

1) emerges fine
QA Notice: you should let portage compress 'man1/vmware.1' for you
[...]
QA Notice: the following files are setXid, dyn linked, and using lazy bindings
 This combination is generally discouraged.  Try re-emerging the package:
 LDFLAGS='-Wl,-z,now' emerge vmware-workstation
LAZY opt/vmware/workstation/bin/vmware-ping
LAZY opt/vmware/workstation/lib/bin/vmware-vmx

2) passes collision protect
3) works

app-emulation/vmware-player-1.0.1.19317-r7:

1) emerges fine
QA Notice: the following files are setXid, dyn linked, and using lazy bindings
 This combination is generally discouraged.  Try re-emerging the package:
 LDFLAGS='-Wl,-z,now' emerge vmware-player
LAZY opt/vmware/player/bin/vmware-ping
LAZY opt/vmware/player/lib/bin/vmware-vmx


QA Notice: the following files contain runtime text relocations
 Text relocations force the dynamic linker to perform extra
 work at startup, waste system resources, and may pose a security
 risk.  On some architectures, the code may not even function
 properly, if at all.
 For more information, see http://hardened.gentoo.org/pic-fix-guide.xml
 Please include this file in your report:
 /var/tmp/portage/vmware-player-1.0.1.19317-r7/temp/scanelf-textrel.log
TEXTREL opt/vmware/player/lib/lib/libgdk-x11-2.0.so.0/libgdk-x11-2.0.so.0


QA Notice: the following files contain executable stacks
 Files with executable stacks will not work properly (or at all!)
 on some architectures/operating systems.  A bug should be filed
 at http://bugs.gentoo.org/ to make sure the file is fixed.
 For more information, see http://hardened.gentoo.org/gnu-stack.xml
 Please include this file in your report:
 /var/tmp/portage/vmware-player-1.0.1.19317-r7/temp/scanelf-execstack.log
RWX --- --- opt/vmware/player/bin/vmnet-natd
RWX --- --- opt/vmware/player/bin/vmnet-dhcpd
RWX --- --- opt/vmware/player/bin/vmware-ping
RWX --- --- opt/vmware/player/bin/vmnet-sniffer
RWX --- --- opt/vmware/player/bin/vmnet-netifup
RWX --- --- opt/vmware/player/bin/vmnet-bridge
RWX --- --- opt/vmware/player/lib/bin/vmplayer
RWX --- --- opt/vmware/player/lib/bin/vmware-vmx
RWX --- --- opt/vmware/player/lib/lib/libpixops.so.2.0.1/libpixops.so.2.0.1
RWX --- --- opt/vmware/player/lib/bin-debug/vmware-vmx

2) passes collision test
3) works

My emerge --info is in comment 10.

PS. I'm still seeing the libpng issue mentioned in comment 10 with both
vmware-workstation and vmware-player. Did anyone ever investigate whether
vmware is vulnerable with regard to bug #138433 ?

app-emulation/vmware-server-console-1.0.1.29996-r2

$ vmware-server-console 
/opt/vmware/server/console/lib/bin/vmware-server-console:
/opt/vmware/server/con
sole/lib/lib/libpng12.so.0/libpng12.so.0: no version information available
(requ
ired by /usr/lib/libcairo.so.2)
/opt/vmware/server/console/lib/bin/vmware-server-console: symbol lookup error:
/
opt/vmware/server/console/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7: undefined
sym
bol: EVP_idea_cbc
/opt/vmware/server/console/lib/bin/vmware-server-console:
/opt/vmware/server/con
sole/lib/lib/libpng12.so.0/libpng12.so.0: no version information available
(requ
ired by /usr/lib/libcairo.so.2)
/opt/vmware/server/console/lib/bin/vmware-server-console:
/opt/vmware/server/con
sole/lib/lib/libpng12.so.0/libpng12.so.0: no version information available
(requ
ired by /usr/lib/libcairo.so.2)
/opt/vmware/server/console/lib/bin/vmware-server-console: symbol lookup error:
/
opt/vmware/server/console/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7: undefined
sym
bol: EVP_idea_cbc

<aol>me too!</aol>

No luck w/ vmware-server{console} -r3 either, the lib gets installed to wrong
location:

# rlocate libcrypto.so.0.9.7
/opt/vmware/server/console/lib/lib/libcrypto.so.0.9.7
/opt/vmware/server/console/lib/lib/libcrypto.so.0.9.7/libcrypto.so.0.9.7

# tail dmesg
vmware-authd[25365]: PANIC: SSLLoadSharedLibrary: Failed to load library
/opt/vmware/server/sbin/libcrypto.so.0.9.7:/opt/vmware/server/sbin/libcrypto.so.0.9.7:
cannot open shared object file: No such file or directory

app-emulation/vmware-workstation-5.5.1.19175-r7 do not work for me. I get the
following error:


SSLLoadSharedLibrary: Failed to load library
/opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:/opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:
cannot open shared object file: No such file or directory

VMware Workstation Error:
VMware Workstation unrecoverable error: (vmui)

(In reply to comment #40)
/opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:/opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:

Something's wrong on your config if it's looking there for the library.  VMware
Workstation should always be looking in /opt/vmware/workstation/lib/lib/* for
its own libraries.


wolf31o2@inertia ~/vmware $ locate libcrypto | grep vmware
/opt/vmware/server/console/lib/lib/libcrypto.so.0.9.7
/opt/vmware/server/console/lib/lib/libcrypto.so.0.9.7/libcrypto.so.0.9.7
wolf31o2@inertia ~/vmware $ vmware-server-console 
/opt/vmware/server/console/lib/bin/vmware-server-console:
/opt/vmware/server/console/lib/lib/libpng12.so.0/libpng12.so.0: no version
information available (required by /usr/lib/libcairo.so.2)
wolf31o2@inertia ~/vmware $

It works fine for me with the files there.  Strange.

(In reply to comment #41)
> (In reply to comment #40)
> /opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:/opt/vmware/workstation/lib/bin/libcrypto.so.0.9.7:
> 
> Something's wrong on your config if it's looking there for the library. VMware
> Workstation should always be looking in /opt/vmware/workstation/lib/lib/* for
> its own libraries.

It happens if libcrypto.so.0.9.7 is removed instead of replaced. Apparently the
last place it searches for it's libs is in lib/bin ...

Right, I've deleted /usr/lib/lib{ssl,crypto}.so-0.9.7 from my system, and I've
installed the most recent vmware-server{,-console} ebuilds that I put in. 
Console starts up fine, but can't connect to the server, it appears as though
vmware-authd is closing immediately.  Trying to run vmware-authd directly
offers the same old:

mike@plasma /opt/vmware/server/sbin $ ./vmware-authd 
./vmware-authd: symbol lookup error:
/opt/vmware/server/lib/lib/libssl.so.0.9.7/libssl.so.0.9.7: undefined symbol:
EVP_idea_cbc

This is with Chris's libcrypto in the same place vmware-server ships it:

mike@plasma /opt/vmware/server $ find . -name libcrypto*      
./lib/lib/libcrypto.so.0.9.7
./lib/lib/libcrypto.so.0.9.7/libcrypto.so.0.9.7
./console/lib/lib/libcrypto.so.0.9.7
./console/lib/lib/libcrypto.so.0.9.7/libcrypto.so.0.9.7

I honestly can't figure out what's going wrong unless there's some screwy
linking going on somewhere.  I do know that I couldn't replicate the problem
until I removed the system versions of libssl-0.9.7 and libcrypto-0.9.7, which
openssl-0.9.8 will keep around on the system for "compatability".

It was quite eye openning to find out that most of my binaries (including wget)
were linked against openssl-0.9.7, which hasn't been patched since 0.9.8 was
installed!  Even revdep-rebuilding didn't seem to help, some of the programs
kept linking against the old openssl versions, which seems a little unsecure to
me...  I'm surprised openssl isn't slotted?

*** Bug 150018 has been marked as a duplicate of this bug. ***

extracting libcrypto and libssl to /opt/vmware/server/lib/bin/ did indeed let
VMWare Server Console start, but it hangs trying to connect.

dmesg shows:
vmware-authd[23319]: segfault at 000000000000000a rip 0000000008064202 rsp
00000000ffa09d20 error 4
vmware-authd[23338]: segfault at 000000000000000a rip 0000000008064202 rsp
00000000fff08fa0 error 4
vmware-authd[23340]: segfault at 000000000000000a rip 0000000008064202 rsp
00000000ff8f8190 error 4

Ugh.. this fixes it:

--- /var/gentoo-x86/eclass/vmware.eclass        2006-10-04 01:07:07.000000000 
+++ /usr/portage/eclass/vmware.eclass   2006-10-04 02:37:13.000000000 +0200
@@ -152,9 +152,9 @@
                        done
                fi
                # Unpack our new libs.
-               [ -d "${DISTDIR}"/vmware-libssl.so.0.9.7l.tar.bz2 ] && \
+               [ -f "${DISTDIR}"/vmware-libssl.so.0.9.7l.tar.bz2 ] && \
                        unpack vmware-libssl.so.0.9.7l.tar.bz2
-               [ -d "${DISTDIR}"/vmware-libcrypto.so.0.9.7l.tar.bz2 ] && \
+               [ -f "${DISTDIR}"/vmware-libcrypto.so.0.9.7l.tar.bz2 ] && \
                        unpack vmware-libcrypto.so.0.9.7l.tar.bz2
        fi
 }

(In reply to comment #46)
Yes, that works for me too. thanks.

(In reply to comment #46)

Yes, it works here too (amd64 profile).

(In reply to comment #46)

It works here, too.

I've updated the vmware overlay for those that desperately need the fix now. 
I'm afraid I'm at work and can't push out to the main tree at the moment, but
if Chris hasn't sorted that by late this evening, I'll push the new eclass into
the tree and bump the vmware-server ebuilds...

Oh, and it's now working for me too (from the overlay)...

OK.  I (finally) have that fixed in the eclass.  I can't believe I made such an
obvious mistake.  Thanks Bo for finding that one!  I apologize for this taking
so long.

Since you guys have tested everything, I'm going to unmask the ebuilds now.

=app-emulation/vmware-player-1.0.1.19317-r7
=app-emulation/vmware-workstation-4.5.3.19414-r7
=app-emulation/vmware-workstation-5.5.1.19175-r7

These need to go stable on x86/amd64.

Comment #36 applies again. I've also tested vmware-server-1.0.1.29996-r3
successfully.

All good now :) Maybe you could revbump vmware-server{,-console} again as well?

Adding arches to CC since this has been sitting for a bit.

hi x86 and amd64 teams,

please test these versions and mark stable if possible, thanks:


=app-emulation/vmware-player-1.0.1.19317-r7
=app-emulation/vmware-workstation-4.5.3.19414-r7
=app-emulation/vmware-workstation-5.5.1.19175-r7

x86 is stable ^.^

Security team, please start to vote on this one.

I think there's no use in sending another GLSA on the RSA forgery issue. I hope
the users who are interested in these kinds of (minor) vulnerabilities are all
warned now.

I don't think anybody is aware of this issue, as even we took a while to find
out.

So that's a yes (and it's a matter of simple reuse, copy-paste, so what gives).

amd64 stable, sorry for the delay

thanks blubb :)

security team please vote. One or two votes needed.

see #58

I agree with frilled

/me votes yes

I think we should be thorough with this.

/vote yes.

let's have one then

i hope i haven't overlooked it here, but questions came up while the GLSA is
drafted/reviewed...

What is the library used for in -workstation and -player (since it appears to
be used for the remote connection in -server) and what would be a possible
impact?
Has vmware been informed about this?

The only evidence I can find of OpenSSL being used in VMware is in the various
VMware-server instances.  As far as I can find, it is only used for serving
some tools, like a management tool, a remote console, and a scripting API.

(In reply to comment #65)
> What is the library used for in -workstation and -player (since it appears to
> be used for the remote connection in -server) and what would be a possible
> impact?

Comment #10 says it doesn't work and I tend to believe him.  What is it used
for? I have no clue.  That's the joy of closed-source applications.

> Has vmware been informed about this?

I have not informed them, no.

Chris, since it appears that nobody has done it so far and we are not going to
release any GLSA based on this little information, could you please try to
contact upstream about this issue?

Sorry, but what am I contacting upstream for here?

*** Bug 159033 has been marked as a duplicate of this bug. ***

I propose closing this with NO GLSA.

i agree and also because of the very weak impact.

Feel free to reopen if you disagree.