Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
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.
