From VMware advisory at $URL: 1. Summary Hosted product updates address a remote code execution vulnerability in the way UDF file systems are handled 2. Relevant releases VMware Workstation 7.1.4 and earlier VMware Player 3.1.4 and earlier VMware Fusion 3.1.2 and earlier 3. Problem Description a. UDF file system import remote code execution A buffer overflow vulnerability is present in the way UDF file systems are handled. This issue could allow for code execution if a user installs from a malicious ISO image that was specially crafted by an attacker.
CVE-2011-3868 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2011-3868): Buffer overflow in VMware Workstation 7.x before 7.1.5, VMware Player 3.x before 3.1.5, VMware Fusion 3.1.x before 3.1.3, and VMware AMS allows remote attackers to execute arbitrary code via a crafted UDF filesystem in an ISO image.
VMware Workstation 7.1.5 and Player 3.1.5 are in the tree.
Does this mean they are ready for stabilization?
@maintainer: are the newest versions in the tree ready for stabilization?
I do not think so.
(In reply to comment #5) > I do not think so. Hi, Vadim. How do we proceed? Should we look to mask the vulnerable versions? Or might you have a time line for getting this bumped? Thanks for your help with this.
(In reply to comment #6) > (In reply to comment #5) > > I do not think so. > > Hi, Vadim. How do we proceed? Should we look to mask the vulnerable versions? > Or might you have a time line for getting this bumped? Thanks for your help > with this. As I understood CVE-2011-3868 the vulnerable configurations are 7.x before 7.1.5 I have removed 7.1.4 bunch from the tree. 7.1.5 is in the tree. They did not mention 6.x. Probably because 6.x is out of support. Because of that there is no bumping for 6. I was thinking to de-stabilize 6 on a ground that it's out of upstream support and require a patch to compile with new kernels. Let me know if I missed something.
(In reply to comment #7) > I was thinking to de-stabilize 6 on a ground > that it's out of upstream support and require a patch to compile with new > kernels. Let me know if I missed something. That sounds alright, but ideally we'd have no vulnerable versions in the tree. If wks 6.x (and 2.x player) go to ~arch, can we then remove them and leave wks 7.1.5 and player 3.1.5 as ~arch? That would be fine with us if that is fine with you.
(In reply to comment #8) > (In reply to comment #7) Do you consider wks 6.5.5, player 2.5.5 vulnerable?
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > Do you consider wks 6.5.5, player 2.5.5 vulnerable? I assume they are, and IMO their advisory is ambiguous, possibly because of end of support. I've asked them to clarify...
(In reply to comment #10) > > I assume they are, and IMO their advisory is ambiguous, possibly because of end > of support. I've asked them to clarify... Here is the response from the VMware security team. > Workstation 6.x or Player 2.x are no longer in support and therefore they > are not in the advisory. > > We have not determined if these versions are affected. Fair enough, I think we need to assume they are vulnerable. Is wks 7 and player 3 as ~arch an acceptable approach? Thanks!
Well, then let's mask 6 bunch and leave 7 as is.
(In reply to comment #12) > Well, then let's mask 6 bunch and leave 7 as is. Are we ready to mask wks 6.x and player 3.x? Would you mind doing that? Thank you.
# Vadim Kuznetsov <vadimk@gentoo.org> (05 Nov 2011) # Masked for removal in 30 days # due to end of support (upstream) and # security issue: bug 385727 <app-emulation/vmware-modules-238.5 <app-emulation/vmware-player-3.1.5 <app-emulation/vmware-workstation-7.1.5
Thanks, Vadim. Added to existing GLSA request.
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).