Bugzilla Bug 213548

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 an attachment (id=146644) [edit]
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.