VMware Security Advisories CVE-2019-5527, CVE-2019-5535 Reproducible: Always
Name: VMware-Workstation-Full-15.5.0-14665864.x86_64.bundle Release Date: 2019-09-19 Build Number: 14665864 MD5SUM: 88cb2ab17815a20f82219aa2f71bbe5b SHA1SUM: 4418d4b3f88aca15c2c4d7b2d26c76641910ae17 SHA256SUM: b557b4dcebefb51466da5b33dc51549537b0d381864b6155c3a48a66801a8597 RELEASE NOTES: https://docs.vmware.com/en/VMware-Workstation-Pro/15.5/rn/VMware-Workstation-155-Pro-Release-Notes.html What's New VMware Workstation 15.5 Pro is a free upgrade for all VMware Workstation 15 Pro users. It includes the following updates: Support for new guest operating systems: Windows 10 19H2 Debian 10.0/10.1 Debian 9.11 Oracle Linux 8.0 SLE 15 SP1 FreeBSD 12.0 PhotonOS 3.0 Jumbo frame support: Virtual networks can now be configured with MTU size of up to 9000 bytes. Preserve Network Configuration: Network settings are now preserved after upgrades. You can also import and export your network configurations. Multiple display shortcut key: You can now quickly adjust the VM display layout with a new keyboard shortcut. PVSCI device support: PVSCSI adapter is now officially supported by Workstation, which enhances the compatibility for VMs migration between Workstation and vSphere. Open VM Tools is the default VMware Tools for applicable Linux virtual machine: For more information, see Workstation 15.5 Pro product documentation. VMware Workstation 15.5 Pro also contains performance improvements, bug fixes and security updates. Important Fixes This release of VMware Workstation Pro addresses the following issues: Workstation 15.5 Pro addresses the use-after-free and denial-of-service vulnerabilities. The Common Vulnerabilities and Exposures project (cve.mitre.org) has assigned the following IDs to these issues : CVE-2019-5527 (use-after-free ) CVE-2019-5535 (denial-of-service) For more information, see VMSA-2019-0014. Implemented DLL loading security improvements, suggested by Peleg Hadar of Safebreach.
VMware Tools 10.3.20 Release Notes Updated on: 19 SEP 2019 VMware Tools | 19 SEP 2019 | Build 14389227 What's New Added new OSS updates for libxml2 and openssl to address security updates. Please take note of the contained End of Feature Support Notice Balloon driver will be removed from MacOS VMware Tools 11.0.0. VMware Tools 10.3.5 freezes feature support for tar tools and OSPs The tar tools (linux.iso) and OSPs shipped with VMware Tools 10.3.5 release will continue to be supported. However, releases after VMware Tools 10.3.5 will only include critical and security fixes and no new feature support in these types of VMware Tools (tar tools and OSP's). It is recommended that customers use open-vm-tools for those operating systems that support open-vm-tools. For more information on different types of VMware Tools, see https://blogs.vmware.com/vsphere/2016/02/understanding-the-three-types-of-vm-tools.html
They also removed the "darwinPre15" tools version.
(Emphasis: from comment #1) > VMware Workstation 15.5 Pro is a free upgrade for all VMware Workstation 15 > Pro users. The existing 15.x License keeps being valid - no new license costs required.
(In reply to Ștefan Talpalaru from comment #3) > They also removed the "darwinPre15" tools version. On the other hand, Windows XP and Vista are still displayed as "Supported Guest System" in the "VMware Compatibility Guide"; thus I expect "winPre2k" and "winPreVista" still remain on the tools list ...
All tool ISOs are missing in the latest Fusion version: https://softwareupdate.vmware.com/cds/vmw-desktop/fusion/11.5.0/14634996/ (no "packages" subdir). Sticking to the old 11.1.0.
Why is the dependency on kernel modules optional? In which scenario would you be running VMware without them?
(In reply to Ștefan Talpalaru from comment #7) > Why is the dependency on kernel modules optional? In which scenario would > you be running VMware without them? Please, remember Bug 604426 - [vmware] app-emulation/vmware-workstation-12.5.8.7098237 : make vmware-modules optional Background: "only use the ease of maintenance" - no VMs are running on local machine - VMs are running on (a) separate ESXi host(s) Thanks again for solving it :-)
Right. Made a note of it in the ebuild.
vmware-workstation-15.5.0.14665864.ebuild available in my overlay, but not keyworded because I can't get past the vmware-setup-helper step of the new configuration. No relevant lines in the logs either.
The good news is that I fixed it in 15.5.0.14665864-r1. The bad news is that installing the server is no longer optional. Without it, there was an unavoidable customisation step that failed as soon as running vmware-setup-helper as root. With the server installed, that part is no longer triggered.
Just discovered a change in naming conventions ? Before: . . . vmware-modules-361.1.0 Now: . . . vmware-modules-15.1.0 . . . vmware-modules-15.5.0-r1
Another hint: Till now, I could restrain "~" like . . . app-emulation/vmware-workstation:0::mkn_local_overlay Now, only . . . app-emulation/vmware-workstation:0 enables the ~ ebuild. Guess this to be related to latest portage changes - will have to find out.
# equery list sys-libs/ncurses [I--] [??] sys-libs/ncurses-5.9-r101:5/5 <--- 5/5 # equery list -p sys-libs/ncurses [IP-] [ ] sys-libs/ncurses-6.1_p20181020:0/6 <--- 0/6 [-P-] [ ~] sys-libs/ncurses-6.1_p20190609:0/6 <--- 0/6 The interim solution was deleted from Main Portage Tree.
Yes, I gave up on upstream's kernel module versioning. Not worth the trouble. They moved "ncurses:5" to "ncurses-compat", but I just checked if any vmware-workstation binary or library uses the system ncurses (or readline for that matter) and I can't find any. I removed them from the dependency list.
Current vmware tools: 11.0.0-14549434 build Date: 2019-09-16T18:55:58.215000-07:00 [ http://softwareupdate.vmware.com/cds/vmw-desktop/ws/15.5.0/14665864/ ]
WORKSFORME: VMware-tools-windows-11.0.0-14549434.iso Installation tested via CD mount / setup64 with WIN 7 / 8.1 / 10 (19H1)
(In reply to Ștefan Talpalaru from comment #15) > ... Not worth the trouble. Well - i.e. disregarding that Tools updates can and do occur during life span of a Workstation version. We had that hint in predecessors of this bug series. But, unfortunately, this does not really make a difference as long as we don't have a working "Tool Upgrade" from *within* VMware Workstation environment, thus being dependent upon the old-school "mount the f... Tools-Upgrade-CD" approach.
Those in vmware-modules are just kernel modules. We don't ship a separate tools package. Just what's in the vmware-workstation archive.
(In reply to Ștefan Talpalaru from comment #19) Sorry for putting it too short, perhaps? [ vmware ] overlay originally kept three separate packages: - vmware-workstation + vmware-player - vmware-modules - vmware-tools enabling independent separate updates. You decided to abandon app-emulation/vmware-tools in 2017: - c.f. Bug 634770 comments 24 and 32 - c.f. Bug 634854 comments 3 In the light of maintenance burden, I still support that and thank you again for all of the work you provided, very much indeed. Kind regards Manfred
HINT: Portage complained about preserved lib /usr/lib64/libpng12.so.0 Neither emerge @preserved-rebuild nor emerge -a --depclean helped. Manually moving it out of the way, re-emerging and starting workstation and VMs succeeded flawlessly: . . . WORKSFORME.
I already have "preserve-libs" in RESTRICT and I don't know of any other mechanism to convince Portage not to look at this package's binaries and libraries when deciding which libraries are being used from other packages.
(In reply to Ștefan Talpalaru from comment #22) > ... "preserve-libs" in RESTRICT $ man 5 ebuild : RESTRICT = [strip,mirror,fetch,userpriv] <--- no "preserve-libs" here ... preserve-libs Disables preserve-libs for specific packages. Note than when a package is merged, RESTRICT=preserve-libs applies if either the new instance or the old instance sets RESTRICT=preserve-libs. ^--- just noting the "either - or" ; what if "both" ? Leaves me in doubt of how to correctly interpret this.
It should also apply when both are true. I think the Portage bug is that this restriction only applies when emerging vmware-workstation, not when uninstalling libpng.
HINT: By the current version . . . app-emulation/vmware-workstation-15.5.0.14665864-r3:0 , current VMSA-2019-0019 is being covered already: . . . "Fixed Version: 15.5.0" [ https://www.vmware.com/security/advisories/VMSA-2019-0019.html ]
Cool. Thanks for keeping an eye on these security advisories!
