| Summary: | [stefantalpalaru overlay] app-emulation/vmware-workstation-15.1.0 version bump ["stable" only, excluding "~amd64"] | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Manfred Knick <Manfred.Knick> |
| Component: | Current packages | Assignee: | Ștefan Talpalaru <stefantalpalaru> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | cam, gentoo, orodruinlair, proteuss, realnc, stefantalpalaru |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Manfred Knick
2018-11-15 18:54:09 UTC
VMware Security Advisory
Advisory ID: VMSA-2018-0027
Severity: Critical
Synopsis: VMware ESXi, Workstation, and Fusion updates address
uninitialized stack memory usage
Issue date: 2018-11-09
Updated on: 2018-11-09 (Initial Advisory)
CVE number: CVE-2018-6981, CVE-2018-6982
:: Workstation 15.x Any Critical 15.0.1 <-----
RDEPEND_ing on masked x11-libs/{lib}gksu :
Please c.f. https://bugs.gentoo.org/663670#c16
vmware-workstation-15.0.1.10737736 and vmware-modules-330.0.1 added to my overlay, without the dependency on gksu [Security-announce] VMSA-2018-0030 "VMware Workstation and Fusion updates address an integer overflow issue" VMware Product Running Replace with/ Mitigation/ Product Version on Severity Apply patch Workaround ========== ======= ====== ======== ============= =========== Workstation 15.x Any Critical 15.0.2 None [ https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-6983 ] version bumped Concerning current k ernel 4.20 : " As expected, the latest NVIDIA (415.25) and VMware (15.0.2) both compile and load/run OK. " [ http://rglinuxtech.com/?p=2474 ] HINT in preparation for upcoming 5.0 : " VMware – Patches Available, for Kernel 5.0-rc1 " [ http://rglinuxtech.com/?p=2477 ] " NVIDIA – New Driver 418.30 – OK with Kernel 5.0 " [ http://rglinuxtech.com/?p=2497 ] Very unfortunately, . . . [vmware-overlay] had to be been closed down and was removed from overlays/repositories.xml: . . . Bug 627666 - vmware: no reply to project status mail . . . [ https://bugs.gentoo.org/627666#c8 ] Currently up-to-date and perfectly working versions of vmware-workstation: c.f. - Bug 663670 and - Bug 671218 HINT concerning vmware-player: - just install above; - vmware-player will be included :-) ATM, further maintenance is continued in (experimental) [ stefantalpalaru ] overlay. Figured this would be the appropriate place to put this since this package isn't in portage: <gnome-base/dconf-0.30.1 is required for vmware-workstation 14 and 15 If using gnome-base/dconf-0.30.1, vmware-workstation will start, but when selecting menu items such as: File->Open Will crash with the error: vmware: symbol lookup error: /usr/lib/gio/modules/libdconfsettings.so: undefined symbol: g_log_structured_standard (In reply to Kenton Groombridge from comment #8) > <gnome-base/dconf-0.30.1 is required for vmware-workstation 14 and 15 Thanks! I updated the ebuilds. > vmware: symbol lookup error: /usr/lib/gio/modules/libdconfsettings.so: > undefined symbol: g_log_structured_standard That's a GLib symbol, weirdly enough. I even tried the latest upstream dconf version with no luck. I don't know what's going on here. (In reply to Manfred Knick from comment #6) > " VMware – Patches Available, for Kernel 5.0-rc1 " 4 new patches for the 5.0.0 kernel applied (but not yet tested with that version) in the vmware-modules ebuilds. All media-libs/tiff-3.x version were removed from portage:
The following unavailable installed packages were found
media-libs/tiff-3.9.7-r1
$ emerge -pv --depclean =media-libs/tiff-3.9.7-r1
Calculating dependencies... done!
media-libs/tiff-3.9.7-r1 pulled in by:
app-emulation/vmware-workstation-15.0.2.10952284-r3 requires media-libs/tiff:3
This means that emerging vmware-workstation will now fail, unless you have it installed already.
Another child of sorrow on the horizon: gnome-base/dconf - workstation requires 0.26.1 - gentoo current stable: [0.30.1] Multiple Security advisories reqire upgrade: --> Fixed Version: VMware Workstation Pro 15.1.0 for Linux 2019-05-14 Build Number: 13591040 https://my.vmware.com/web/vmware/details?downloadGroup=WKST-1510-LX&productId=799&rPId=33370 Kernel – 5.2-rc1 Released – Mostly Harmless.. OK this time, with the latest NVIDIA (430.14), and with patched VMware 15.1.0. It still includes the annoying weird logic change to # make xconfig, so I will be producing an – unofficial – patch to revert this, soon. [ http://rglinuxtech.com/?p=2567 ] The dconf version requirement was already fixed: https://github.com/stefantalpalaru/gentoo-overlay/issues/37 vmware-workstation-15.1.0.13591040 and the associated kernel modules are now available in my overlay. (In reply to Ștefan Talpalaru from comment #15) Thanks to Stefan! That was quick again. CONFIRMATION: WORKSFORME (usual quick tests as always). VMware Tools identify for an update being available: . . . VMware Tools 10.3.10 . . . Aktualisiert am: 20. März 2019 . . . VMware Tools | 14. März 2019 | Build 12406962 [https://docs.vmware.com/de/VMware-Tools/10.3/rn/vmware-tools-10310-release-notes.html] Installing Tools: Download ISO from . . . [https://packages.vmware.com/tools/releases/index.html] and mount the ISO as CD/DVD into your VM Devices. Stefan, the ebuild depends upon "virtual/jpeg:62" which is not in MPT any more; only "virtual/jpeg-0-r3:0" is left. Will have a look at that tomorrow. How about we stop supporting installs without bundled libs? Having to fork old package versions just to save 116MiB of storage space is getting ridiculous. That support also increases the maintenance complexity with each release. (ADDENDUM to comment #16) > Installing Tools: Alternatively, one directory below, you also find executables for installation via starting the corresponding .exe for {i386|x86_64} (In reply to Ștefan Talpalaru from comment #18) Hi, Stefan, thanks for adapting the BUNDLED_LIB_DEPENDS from libjpeg:62 to virtual/jpeg-compat and providing the updated versions in your overlay: commit 01c9aa81517e69c3cdf33ba0fe8f7cab84b3110c WORKSFORME. @ newcomers: reference: $ layman -i stefantalpalaru > How about we stop supporting installs without bundled libs? A very legitimate question, indeed. @ newcomers: background: VMware's primary interests rest upon their own infrastructure, M$ Server and Windows Desktop interaction as a second. After a long pause, Linux Enterprise hold up their head; Linux Desktop being fobbed off with openSUSE and Ubuntu, serving as fig leafs on the front page as an excuse. Which explains why VMware's efforts to support up-to-date versions in a timely manner is 'limited', to put it judicious: outdated library versions used in RHEL and SLES match e.g. those in Debian 9.4; Fedora 28 is already EOL (!) since 2019-05-28. Reference: "Supported host operating systems" [ https://kb.vmware.com/s/article/2129859 ]. That's the background why I forced the separation of bug reports between "stable" and "~" installations, concentrating on "stable" exclusively, because expecting this closed-source beast even to run with "~" was outright ridiculous, putting "reliably" aside. > Having to fork old package versions > just to save 116MiB of storage space <----- > is getting ridiculous. That's correct. But in my view, the issue is not that much about saving space - it's about having the libs compiled "The Gentoo Way", with all the preferred options for the intended installation,e.g. - CFLAGS optimization settings, - "-march=native" - USE flags and so on, not surrendering to VMware's build process more than absolutely necessary. > That support also increases the maintenance complexity with each release. Admitting that there is no support from any Gentoo Developers, we might face this option as a necessity. However tempting, my plea is "Let us delay this step as long as possible". Kind regards Manfred P.S.: You took notice of 14.x EOL [ https://bugs.gentoo.org/663670#c21 ] ? Are you aware of any justified needs to keep 14.x in your overlay ? > You took notice of 14.x EOL [ https://bugs.gentoo.org/663670#c21 ] ? Yes. > Are you aware of any justified needs to keep 14.x in your overlay ? Some people think that an EOL does not justify paying for a 15.x license. It's no big deal keeping that 14.x ebuild around for that purpose and no risk of new users using the old version by mistake. (In reply to Ștefan Talpalaru from comment #21) > Some people think that an EOL does not justify paying for a 15.x license. That's their problem. And your > ... increase[d] the maintenance complexity ... > It's no big deal ... That is no justification to actively support security breaches classified by CVEs. I did fight that habit for years against [vmware overlay]. It's ridiculous to "tighten" Gentoo against ... and keeping barn doors wide open at the same time: irresponsible. What about supporting non-bundled libraries and thus straying from upstream's tested setup in the name of more freedom for Gentoo users? Are we sure there's no CVE appearing just in a newer version of those 53 packages we override by default? Just as well, newer versions of those libraries may fix older bugs that VMware is not considering yet. Choices have consequences and Gentoo users are responsible for them. Our job is to provide sane defaults and get out of the way. The sane default here is the latest version: 15.1.0. By the way, the "bundled-libs" USE flag should be enabled by default. It comes with fewer problems for the user. (In reply to Ștefan Talpalaru from comment #23) > By the way, the "bundled-libs" USE flag should be enabled by default. It > comes with fewer problems for the user. Agreed: IUSE=" ... +bundled-libs " ...................^ (In reply to Ștefan Talpalaru from comment #23) > Choices have consequences and Gentoo users are responsible for them. > Our job is to provide sane defaults and get out of the way. Why do we prune Main Portage Tree, then? Deleting old / buggy / broken kernel versions, web browsers, etc. pp. ? > The sane default here is > the latest version: 15.1.0. How is a new user expected to detect that from your overlay? AFAICS, 14.x is not especially "hard-masked" in any way: KEYWORDS="~amd64" <---- same as in 15.1.0 There is no EWARN "This version is EOL: Use at your own risk!" EWARN "This version is EOL: Do not imperil others!" In case it is and I overlooked that: correct me, please. Keywords removed and warning added to the 14.x ebuild. (In reply to Ștefan Talpalaru from comment #23) > ... those 53 packages we override by default ... As far as I remember from my last inspection, VMware's original installer itself *only* uses its packaged versions if no adequate library can be found being already installed on the system for substitution. Such a library check would be surprising. Why would they want to support arbitrary libraries already installed on dozens of different distributions? Also, why wouldn't the check work in the Portage sandbox - there's no shortage of packages that need to have their automagic dependencies disabled in the configuration phase because they try to bee too smart about it. (In reply to Manfred Knick from comment #27) ... > As far as I remember from my last inspection, VMware's original installer > itself *only* uses its packaged versions if no adequate library can be found > being already installed on the system for substitution. Some hours of sleep helped sorting remembrance: It's even processed during run-time, @ start-up, to be precise. Please c.f. /tmp/vmware-<username>/vmware-apploader-*.log e.g. $ grep -i { "shipped", "system", "library" } (Bug 562836 from 2015 is one of the examples fighting to sort out those lists.) (In reply to Ștefan Talpalaru from comment #28) > ... surprising. Why would they want to support > arbitrary libraries already installed on dozens of different distributions? They don't. The adjective "adequate" in comment #27 was not surplus. (In reply to Ștefan Talpalaru from comment #26) > Keywords removed and warning added to the 14.x ebuild. Thanks a lot! CONFIRMATION: WORKSFORME, even Upgrade Win-10 to Redstone 19H1 and Manage > Change Hareware Compatibility --> Workstation 15.x --> Alter this machine (Take a snapshot beforhand.) Closing as FIXED, thanks to Stefan again! I see that the runtime dynamic lib path confusion was solved with an env var: https://bugs.gentoo.org/562836#c25 It works properly to this day, according to "vmware-apploader-*.log". (In reply to Ștefan Talpalaru from comment #30) > It works properly to this day, according to "vmware-apploader-*.log". Yes, indeed. HINT: [Security-announce] VMSA-2019-0009 VMware Tools and Workstation updates address out of bounds read and use-after-free vulnerabilities. (CVE-2019-5522, CVE-2019-5525) [https://www.vmware.com/security/advisories/VMSA-2019-0009.html] Concerning Workstation: We are @ "Fixed Version" 15.1.0 already. Concerning Tools: Perhaps you could include an additional EWARN to upgrade to "latest version, at least 10.3.10" from within the VMs? > Perhaps you could include an additional EWARN
> to upgrade to "latest version, at least 10.3.10" from within the VMs?
Please make a PR on GitHub. Remember to bump the ebuild's revision number.
(In reply to Ștefan Talpalaru from comment #32) > Please make a PR on GitHub. ehm ... R u kidding? WARNING concerning current Version 15.1.0: (RE-) Configuration via Edit -> Virtual Network Editor fails: »/opt/vmware/bin/vmware-netcfg« ... (No such file or directory) Manually extracting and inverstigating VMware-Workstation-Full-15.1.0-13591040.x86_64.bundle reveals: $ find . -name "*netcfg*" ./vmware-network-editor/lib/libvmware-netcfg.so ./vmware-network-editor/lib/libvmware-netcfg.so/libvmware-netcfg.so ./vmware-network-editor-ui/share/applications/vmware-netcfg.desktop ./vmware-network-editor-ui/share/icons/hicolor/256x256/apps/vmware-netcfg.png ./vmware-network-editor-ui/share/icons/hicolor/22x22/apps/vmware-netcfg.png ./vmware-network-editor-ui/share/icons/hicolor/24x24/apps/vmware-netcfg.png ./vmware-network-editor-ui/share/icons/hicolor/48x48/apps/vmware-netcfg.png ./vmware-network-editor-ui/share/icons/hicolor/32x32/apps/vmware-netcfg.png ./vmware-network-editor-ui/share/icons/hicolor/16x16/apps/vmware-netcfg.png i.E. the bundle contains necessary libraries involved, but misses the corresponding executable, indeed. Version 15.0.? did contain the vmware-netcfg command. So far, only one related entry found in VMware Communities yet: . . . https://communities.vmware.com/message/2867073#2867073 That was fixed on June 7, in vmware-workstation-15.1.0.13591040-r4: https://github.com/stefantalpalaru/gentoo-overlay/commit/b6383eb6294b167855dcd530289a34bde8959e81 (In reply to Ștefan Talpalaru from comment #35) Sorry for having overlooked -r4. Erasing all config (etc as well as user), re-installing -r4 a-new: Fail Network configuration is missing. Ensure that /etc/vmware/networking exists. Calling "emerge --config" creates full default setup. Thereafter, vmware-netcfg WORKSFORME: - calling via Menu as well as - calling via command line vmware: symbol lookup error: /usr/lib/gio/modules/libdconfsettings.so: undefined symbol: g_log_structured_standard Was this ever fixed? Using: vmware-workstation-15.5.6.16341506-r2 dconf-0.36.0 glib-2.64.5 (In reply to Rich Surgenor from comment #37) > vmware: symbol lookup error: /usr/lib/gio/modules/libdconfsettings.so: > undefined symbol: g_log_structured_standard > > Was this ever fixed? Using: > vmware-workstation-15.5.6.16341506-r2 > dconf-0.36.0 > glib-2.64.5 You need to either downgrade to dconf 0.26.1, or edit /etc/env.d/90vmware and delete VMWARE_USE_SHIPPED_LIBS=1 Then do env-update and reboot. |