There is a new version of vmware workstation out as of 3/14/2008. The current ebuilds are not compatible with this version. Please add to portage with testable ebuilds, masked for arch. Reproducible: Always Steps to Reproduce: 1. emerge arch vmware-workstation with ~x86 or ~x86_64 2. 3. Actual Results: current ebuilds are unable to fetch vmware-workstation 6 versions. Expected Results: vmware-workstation 6 should be installed
5.5.6 has been released, fixing the very same issues, too. While we're at it: I don't understand 4.5.3 isn't masked since the last VMware vulnerability update. For whom it isn't an issue, because the VM guests are not exposed, can unmask it, but for everyone else we should assure even the problem will be noticed, even if the user does not care about GLSAs.
I've bumped workstation to 6.0.3 and player to 2.0.3 in the vmware overlay for a quick bit of testing. Server{-console}-1.0.5 is causing a few issues relating to gcc-4.2.0 compilation vs gcc-4.2.3 runtime, so will take me a bit longer to get a suitable fix in place. Chris has historically dealt with workstation < 6, and I don't have licenses for those versions, so I'm inclined to leave those with him. Please note, the openssl fixes rolled into this update I think were covered by our fix for bug 148682, so I'm not certain how critical this update actually is...
(In reply to comment #2) > I've bumped workstation to 6.0.3 and player to 2.0.3 in the vmware overlay for > a quick bit of testing. Server{-console}-1.0.5 is causing a few issues > relating to gcc-4.2.0 compilation vs gcc-4.2.3 runtime, so will take me a bit > longer to get a suitable fix in place. Chris has historically dealt with > workstation < 6, and I don't have licenses for those versions, so I'm inclined > to leave those with him. > > Please note, the openssl fixes rolled into this update I think were covered by > our fix for bug 148682, so I'm not certain how critical this update actually > is... > Thanks, I've pulled it from the overlay and it's working well. There is a question about the vmware-modules version (there's a 1.0.0.18) version that's getting pulled in at the moment that wants to unmerge workstation 6.0.3, but I just masked it.
vmware-modules-1.0.0.18 is for vmware-server-2 (which is badly broken at the moment), so you did the right thing by masking it, just be aware if you ever want to try out server-2, you'll need to unmask it again... 5:)
*** Bug 213864 has been marked as a duplicate of this bug. ***
FYI: renaming vmware-server-1.0.4.56528.ebuild to vmware-server-1.0.5.80187.ebuild and then merging worked without any problems, VMWare runs fine. All patches are still needed. BTW: Is there any source where people can look for the purpose of a specific patch? Reviewing all patches is probably not very efficient.
Craig, There's an issue for some people using GCC 4.2.3 that causes vmware-server-console-1.0.5 (and, as it turns out, 1.0.4) not to run because of the packaged libgcc_s.so.1 looking for gcc-4.2.0. I'd like to get this fixed before rushing out a version bump and then having to bump again with the fix. Please note that many of the vulnerabilties listed in the advisory were pertinent to windows systems running vmware, and the openssl issues were manually fixed by us earlier. The only flaw that seems to directly affect us is use of an old libpng... The patch names or the contents of the patches themselves are the only method to determine if they're still needed. Having written most of the patches, they relate mostly to altering the startup scripts to work in a Gentoo environment, and so will always be necessary. Getting Gentoo installed through portage is not an easy task and takes a bit of mangling, as the patches show... 5;)
I know it's not that easy, especially for packages like VMWare! I also reviewed all the patches. :) Thanks for the clarification and good work. As soon as 1.0.5 is in Portage, I'll upgrade several machines here and will report back wheather if it causes any problems or not.
Created attachment 146644 [details] vmware-workstation-5.5.6.80404.ebuild Hi, I already posted this to the vmware alias list, but got no answer. So trying here. I have been working on a modified ebuild for vmware-ws-5.5.6 build 80404. It still has problems, but may help to build a valid one.
*** Bug 214044 has been marked as a duplicate of this bug. ***
CVE-2008-1340 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1340): Virtual Machine Communication Interface (VMCI) in VMware Workstation 6.0.x before 6.0.3, VMware Player 2.0.x before 2.0.3, and VMware ACE 2.0.x before 2.0.1 allows attackers to cause a denial of service (host OS crash) via crafted VMCI calls that trigger "memory exhaustion and memory corruption." CVE-2008-1361 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1361): VMware Workstation 6.0.x before 6.0.3 and 5.5.x before 5.5.6, VMware Player 2.0.x before 2.0.3 and 1.0.x before 1.0.6, VMware ACE 2.0.x before 2.0.1 and 1.0.x before 1.0.5, and VMware Server 1.0.x before 1.0.5 on Windows allow local users to gain privileges via an unspecified manipulation that causes the authd process to connect to an arbitrary named pipe, a different vulnerability than CVE-2008-1362. CVE-2008-1362 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1362): VMware Workstation 6.0.x before 6.0.3 and 5.5.x before 5.5.6, VMware Player 2.0.x before 2.0.3 and 1.0.x before 1.0.6, VMware ACE 2.0.x before 2.0.1 and 1.0.x before 1.0.5, and VMware Server 1.0.x before 1.0.5 on Windows allow local users to gain privileges or cause a denial of service by impersonating the authd process through an unspecified use of an "insecurely created named pipe," a different vulnerability than CVE-2008-1361. CVE-2008-1363 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1363): VMware Workstation 6.0.x before 6.0.3 and 5.5.x before 5.5.6, VMware Player 2.0.x before 2.0.3 and 1.0.x before 1.0.6, VMware ACE 2.0.x before 2.0.1 and 1.0.x before 1.0.5, and VMware Server 1.0.x before 1.0.5 on Windows allow local users to gain privileges via an unspecified manipulation of a config.ini file located in an Application Data folder, which can be used for "hijacking the VMX process." CVE-2008-1364 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1364): Unspecified vulnerability in the DHCP service in VMware Workstation 5.5.x before 5.5.6, VMware Player 1.0.x before 1.0.6, VMware ACE 1.0.x before 1.0.5, VMware Server 1.0.x before 1.0.5, and VMware Fusion 1.1.x before 1.1.1 allows attackers to cause a denial of service. CVE-2008-1392 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-1392): The default configuration of VMware Workstation 6.0.2, VMware Player 2.0.x before 2.0.3, and VMware ACE 2.0.x before 2.0.1 makes the console of the guest OS accessible through anonymous VIX API calls, which has unknown impact and attack vectors.
We have the following targets to meet in the tree: =app-emulation/vmware-workstation-5.5.6.79688 KEYWORDS="amd64 x86" =app-emulation/vmware-workstation-6.0.3.80004 KEYWORDS="~amd64 ~x86" =app-emulation/vmware-server-1.0.5.79847 KEYWORDS="~amd64 x86" =app-emulation/vmware-player-1.0.6.79688 KEYWORDS="amd64 x86" =app-emulation/vmware-player-2.0.3.80004 KEYWORDS="~amd64 ~x86" vmware herd, how far along are we here?
Ok, now in the tree are: =app-emulation/vmware-workstation-6.0.3.80004 KEYWORDS="~amd64 ~x86" =app-emulation/vmware-server-1.0.5.80187 KEYWORDS="~amd64 ~x86" =app-emulation/vmware-server-console-1.0.5.80187 KEYWORDS="~amd64 ~x86" =app-emulation/vmware-player-1.0.6.80404 KEYWORDS="~amd64 ~x86" =app-emulation/vmware-player-2.0.3.80004 KEYWORDS="~amd64 ~x86" Herdstat says Chris is away, so I'm not sure about workstation 5.5.6. It should be a simple bump, but I can't test it easily myself. player-1.0.6, server-console-1.0.5 and probably workstation-5.5.6 all have an issue (it was apparently present in earlier versions, but no one reported it), whereby the version of gcc vmware compiled them with causes a mismatch and they won't start. All OSes appear to be seeing this. There's nothing we can easily/reliably do in the ebuild, but there is a potential workaround. With Chris away, and me off for easter in an hour or two, it would be good if security@g.o could mask/stable request themselves, if they feel it necessary. Thanks... 5:)
OK, I'm hitting the GCC error with 5.5.6, which is now in the overlay. I'll be looking into this more and will try to get it fixed and in the tree ASAP.
OK, 5.5.6.80404 is now in the tree.
Thanks Chris ;).
Arches, please test and mark stable: =app-emulation/vmware-workstation-5.5.6.80404 KEYWORDS="amd64 x86" =app-emulation/vmware-server-1.0.5.79847 KEYWORDS="~amd64 x86" =app-emulation/vmware-player-1.0.6.79688 KEYWORDS="amd64 x86"
Isn't it 1.0.5.80187 instead of app-emulation/vmware-server-1.0.5.79847 and app-emulation/vmware-player-1.0.6.80404 instead of app-emulation/vmware-player-1.0.6.79688?!?
Craig, you are obviously right. Seems I copied from the wrong post. -- Arches, please test and mark stable: =app-emulation/vmware-workstation-5.5.6.80404 KEYWORDS="amd64 x86" =app-emulation/vmware-server-1.0.5.80187 KEYWORDS="~amd64 x86" =app-emulation/vmware-player-1.0.6.80404 KEYWORDS="amd64 x86"
(In reply to comment #19) > Craig, you are obviously right. Seems I copied from the wrong post. > > -- > > Arches, please test and mark stable: > =app-emulation/vmware-workstation-5.5.6.80404 KEYWORDS="amd64 x86" > =app-emulation/vmware-server-1.0.5.80187 KEYWORDS="~amd64 x86" > =app-emulation/vmware-player-1.0.6.80404 KEYWORDS="amd64 x86" > any news here?
x86 stable, sorry for the delay.
(In reply to comment #21) > x86 stable, sorry for the delay. same for amd64. all arches done.
glsa request filed.
Fixed in release snapshot.
@security: is the only thing missing here (since 2008) the GLSA? Then we can probably safely forget about this bug...
This issue was resolved and addressed in GLSA 201209-25 at http://security.gentoo.org/glsa/glsa-201209-25.xml by GLSA coordinator Sean Amoss (ackle).
