Summary: | app-emulation/vmware-workstation possible overflow | ||
---|---|---|---|
Product: | Gentoo Security | Reporter: | Sune Kloppenborg Jeppesen (RETIRED) <jaervosz> |
Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | ignoreme, vmware+disabled |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://archives.neohapsis.com/archives/fulldisclosure/2005-12/1068.html | ||
Whiteboard: | B1 [glsa] | ||
Package list: | Runtime testing required: | --- |
Description
Sune Kloppenborg Jeppesen (RETIRED)
2005-12-20 23:18:31 UTC
Upstream response: http://www.securityfocus.com/archive/1/420017/30/0/threaded And sorry for accidentially filing this as restricted yesterday. *** Bug 116292 has been marked as a duplicate of this bug. *** OK. I am /away until after the first of the year (and the only active person on the VMware team) starting today. Upgrading to a non-vulnerable version for users of 3.2.1 and 4.5 costs money, so that isn't a viable option. The "default" is bridged networking, but that can be simply changed. Getting 5.5.1 marked stable on x86/amd64 will solve the issue for anyone running 5.x, but it won't help users running 3.x or 4.x... If the vmware-any-any-update96 patch resolves this for those users, then they're already fixed in stable. The 96 patch is dated Nov 16 and the vulnerability was reported to VMWare on Dec 1, so it's probably not fixed in it. I would call for the (fixed) 5.5.1.19175 to become stable and publish a GLSA with the workaround available to other versions users. If/when a patch or new version is available for the other versions we'll update the GLSA accordingly. According to bigbabyjesusfoo and r2d2 in #gentoo-security there's a new 4.5.3 build 19414 dated 12/27/05 that's also a fix for this so it'll need updating also. It's unclear if 3.x is affected, if it it could do with masking. <r2d2> 5.0 remains vulnerable and 5.5.1 is the security fixed version of 5.5.0 AFAIK 5.5 is key-compatible with 5.0 so we probably want to urge people to upgrade if a new build for 5.0 doesn't come out. Yes, we could target 4.5.3 and 5.5.1 for stable, and mask all affected versions, then release a GLSA about this. We can update that GLSA if/when a 3.x version gets released, otherwise it will just show as affected. I am currently working on new ebuilds for 4.5.3 and will stabilize 5.5.1 with it. Ebuilds are in CVS and marked stable. Can someone verify 3.2.1, as I only have an AMD64 box available and this version doesn't run on AMD64. Calling in x86 to test as per above comment. Not sure what to test... there is a 3.2.1 fixed version somewhere ? Or do you want someone to check that 3.2.1 is affected ? That version has been stable for a couple weeks now. No idea how to test if its vulnerable, and if it is, upstream isn't going to be pushing out any new versions of it anyway (I don't think). Chris: is there any work left to do, like something about the 3.x version (implied by your comment #9) ? GLSA is ready to go if you confirm it's OK. The latest version of vmware-player in portage is also fixed (as of today) but was never marked stable. As for 3.x, there does not appear to be a new version and I cannot verify that 3.x is vulnerable. I have considered adding a masking simply stating that there are some known issues with the VMware NAT code and that 3.x is potentially vulnerable, but really would like some guidance or advice on what you guys think. I'm pretty sure 3.x is affected. From VMware inc. : "The vulnerability in the NAT component affects VMware Workstation 5.5, VMware GSX Server 3.2, VMware ACE 1.0.1, VMware Player 1.0, and previous releases of these products" Also from my own knowledge of vmware-nat, if there was an error in there, it's probably been there from the beginning. So masking with a message is OK. 3.x is now masked... GLSA 200601-04 I believe that this was fixed for the 3.x branch with vmware-any-any-update97. On March 20th, a new revision was added for 3.x that brought us to vmware-any-any-update98. Since this was the first update based off the VMware Workstation 5.5.1, it had the security bug already fixed. Can we possibly update the GLSA so that ferringb's vulnerability scan will no longer find this version vulnerable, since it is not. updated GLSA in cvs |