Core Security Technologies Advisory 2007.0930

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA1  
  
  
~ Core Security Technologies - CoreLabs Advisory  
~ http://www.coresecurity.com/corelabs  
  
Path Traversal vulnerability in VMware's shared folders implementation  
  
*Advisory Information*  
  
Title: Path Traversal vulnerability in VMware's shared folders implementation  
Advisory ID: CORE-2007-0930  
Advisory URL: http://www.coresecurity.com/?action=item&id=2129  
Date published: 2008-02-25  
Date of last update: 2008-02-25  
Vendors contacted: VMware Inc.  
Release mode: User release  
  
*Vulnerability Information*  
  
Class: Input Validation Error  
Remotely Exploitable: Yes  
Locally Exploitable: Yes  
Client-side Exploitable: No  
Bugtraq ID: 27944  
CVE Name: CVE-2008-0923  
  
*Vulnerability Description*  
  
Software from VMWare Inc. allows users to run an entire computer system  
composed of hardware, OS and applications within a virtualized environment  
isolated from the real hardware resources and the computer system that  
controls them. Virtualization technologies such as VMware's increase  
efficiency in the use of hardware and help to reduce operational costs  
through consolidation of servers and desktop system running on fewer and  
more maintainable hardware systems.  
  
Among the many reasons that promote the adoption virtualization  
technologies, one of the most commons today is the promise of an improved  
information security posture due to the implied isolation between multiple  
virtualized systems (referred as Guest systems) and the non-virtualized  
systems controlling the virtualization hardware and software (the Host  
system) [1].  
  
Consequently, software bugs that could allow potential attackers to  
invalidate the premise of effective isolation between Host and Guest  
systems are considered security vulnerabilities with a potentially high  
impact. Attacks to exploit these type of vulnerabilities has been  
discussed on several public forums [2][3]. To maintain and improve user  
inter-operation with virtualized and non-virtualized systems VMware's  
software implements a number of inter-system communication features. The  
Shared Folder mechanism is one of such features and is enabled by default  
in all VMware's products that provide it.  
  
VMware's shared folders allow users to transfer data between a virtualized  
system (Guest) and the non-virtualized Host system that contains it. This  
form of data transfer is available to users of the Guest system through  
read and write access to file system folders shared by both Guest and Host  
system. To maintain effective isolation between Guest and Host systems,  
these mechanisms should limit access from the Guest only to the Host  
system's folders that are selected for sharing with the virtualized guests.  
  
A vulnerability was found in VMware's shared folders mechanism that grants  
users of a Guest system read and write access to any portion of the Host's  
file system including the system folder and other security-sensitive  
files. Exploitation of these vulnerability allows attackers to break out  
of an isolated Guest system to compromise the underlying Host system that  
controls it.  
  
Successful exploitation requires that the Shared Folder's feature to be  
enabled which is the default on VMware products that have the feature AND  
at least one folder of the Host system is configured for sharing.  
  
*Vulnerable Packages*  
  
. VMWare Workstation 6.0.2  
. VMWare Workstation 5.5.4  
. VMWare Player 2.0.2  
. VMWare Player 1.0.4  
. VMWare ACE 2.0.2  
. VMWare ACE 1.0.2  
  
*Non-vulnerable Packages*  
  
. VMWare ESX  
. VMWare Server  
  
*Vendor Information, Solutions and Workarounds*  
  
Disable the Shared Folders feature for all virtual machines. On VMWare  
Workstation this can be done by clicking on "Edit virtual machine  
settings" and disabling shared folders in the Options tab.  
  
The vendor has published a security alert with a setp-by-step description  
of how to disable Shared Folders on affected products.  
  
*Critical VMware Security Alert for Windows-Hosted VMware Workstation,  
VMware Player, and VMware ACE*  
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004034  
  
*Credits*  
  
This vulnerability was discovered by Gerardo Richarte while developing an  
exploit for vulnerability CVE-2007-1744. The final exploit for both  
vulnerabilities was developed by Nicolas Economou, both of them from CORE  
IMPACT's Exploit Writing Team (EWT), Core Security Technologies.  
  
*Technical Description / Proof of Concept Code*  
  
While developing an exploit for the CVE-2007-1744 vulnerability [4] the  
root cause of the original bug was identified in the way that the  
'PathName' parameter is processed by the VMware API that provides the  
Shared Folders functionality in the Guest operating system.  
  
The 'PathName' parameter is converted from a multi byte string to a wide  
character string after verifying that it doesn't contain the dot-dot  
substring (the two-byte sequence '0x2e0x2e' that translates to the ASCII  
substring '".."') that may allow a malicious user to break out of the  
shared folder using a path traversal attack. The resulting wide character  
string converted from 'PathName' is then passed to the file system API on  
the Host system.  
  
The conversion is performed using the 'MultiByteToWideChar' function from  
the Windows API [5] which maps a character string provided as input to a  
wide (Unicode UTF-16) character string.  
  
The call of 'MultiByteToWideChar' to map the 'PathName' to Unicode UTF-16  
specifies that the UTF-8 CodePage should be used for the conversion. Since  
validation of the input to remove the dot-dot substring is performed  
before the input string is converted a malicious program or user on the  
Guest system could provide a 'PathName' that passes this validation  
process but still gets mapped to a string containing the Unicode UTF-16  
version of the dot-dot- substring after the call to 'MultiByteToWideChar'.  
  
A UTF-8 byte sequence that translates to said dot-dot substring is  
'%c0%2e%c0%2e'. This sequence is well-known among web application  
penetration testers that use regularly to attempt to escape the root  
document folder of a web application prone to path traversal  
vulnerabilities. Although the above byte sequence is not in valid UTF-8  
encoding a call to the 'MultiByteToWideChar' function that does not set  
the second argument ('dwFlags') to 'MB_ERR_INVALID_CHARS' will simply  
ignore and discard any invalid characters on input and map the rest to  
Unicode output .  
  
Prior to CVE-2007-1744 the call to 'MultiByteToWideChar' was . performed  
with a 'dwFlags' argument set to 0, thus allowing an attacker to pass  
invalid UTF-8 input that would pass the verification process and get  
translated by 'MultiBytetoChar' to a string that includes the dot-dot  
substring .  
  
The fix to CVE-2007-1744 [6] consisted in setting the  
'MB_ERR_INVALID_CHARS' flag to the function call thus making it fail  
(setting the error code to 'ERROR_NO_UNICODE_TRANSLATION') if non-valid  
UTF-8 input was provided.  
  
However, since the inspection of input looking for the evil dot-dot  
substring remained a step prior to its mapping to Unicode UTF-16 the basic  
execution flow for a potential attack did not change. After the fix for  
CVE-2007-1744 an attacker would only need a way to provide a valid UTF-8  
string that passes input sanitization AND the call to 'MultiByteToChar'  
but still yield an string that contains the malicious dot-dot substring  
after the mapping.  
  
When we originally found this, we were not sure if it was possible to pass  
the call to 'MultiByteToWideChar' with the 'MB_ERR_INVALID CHARS' flag set  
but research continued due to the belief that the patch was not  
necessarily correct since we thought that proper filtering had to be done  
only after all the translations of the input were completed and prior to  
passing the results to the Host's system file system layer.  
  
Although we live in a ISO 8851-1 Latin 1 (28591) codepage-speaking country  
we don't really know the deepest secret internals of UTF-8 , multi-byte  
strings and Unicode conversions. Thus we developed a small program that  
reproduces how vmware-vmx.exe calls 'MultiByteToWideChar()' to find out  
whether it is possible or not to build a valid UTF-8 sequence that maps to  
an Unicode string with the evil dot-dot substring '_.._ '  
  
The C code for such program is provided below  
  
/-----------  
  
// mbtwc.c  
#include <windows.h>;  
int main(int argv, char *argc[]) {  
~ unsigned int i, ans;  
~ unsigned char buf[200];  
~ for (i=1;i;i++) {  
~ memset(buf, 0, 200);  
~ ans = MultiByteToWideChar(CP_UTF8, 8, &i, 4, buf, 100);  
~ // 8 = MB_ERR_INVALID_CHARS  
~ if (ans && (buf[0] == '.') && (buf[1] == 0) &&  
~ ((i & 0xff) != '.'))  
~ printf("%d %04x: %02x %02x %02x %02x\n", ans, i,  
~ buf[0], buf[1], buf[2], buf[3]);  
}  
~ }  
- -----------/  
  
The program found several UTF-8 byte sequences that traslate to a dot-dot  
substring after the call to 'MutliByteToWideChar', the first one of them  
being '"0xc20x2e0xc20x2e_'.  
  
In order to develop test tools and the final exploit we used the wonderful  
information and tools released at the VM Back project [7]by Ken Kato and  
other contributors. Using the project's VMFtp tool with a few  
modifications it is trivial to produce a working exploit. Our approach for  
a proof-of-concept test was to modify VMFtp's source code to replace all  
occurrences of ''+'' with ''\xc2'' in an input pathname.  
  
After doing the above, the following command on a modified VMFtp client  
list the contents of the root directory of the Host's file system and then  
uploads a file from the Guest system to the root directory of the Host system.  
  
/-----------  
  
cd existing_share  
ls +.+./+.+./+.+./+.+./+.+./+.+./  
put myboot.ini +.+./+.+./+.+./+.+./+.+./+.+./+.+./+.+./boot.ini  
  
- -----------/  
  
  
  
Additionally, we tried to find out whether it's possible or not to exploit  
this bug when no shared folders are configured but the Shared Folders  
feature is enabled (as in a default installation). Due to what we believe  
is an early check in the implementation to verify if the linked list of  
existing shares is empty or not, we think that this bug is not exploitable  
when no folders are configured as shared, however, we wouldn't be  
surprised if other execution paths that allow exploitation bypassing this  
early check are found. Consequently, we suggest that you update to a fixed  
version, even if no folders are shared for your configurations. If this is  
not a possibility, we suggest that you at least disable the Shared Folders  
feature, which, as we said, is enabled by default.  
  
Additional Information  
  
Here we present the minimum modifications to VMFtp from the VMBack project  
to build something that will help you demonstrate the importance of the  
bug, verify if the your boxes are patched or not, and if the official  
patch actually patched the vulnerability.  
  
Modifications to the file vmw/src/vmshf.c:  
  
/-----------  
  
static void ReplaceDelim(char *str, uint32_t length, char delim)  
{  
~ while (length--) {  
~ if (*(str + length) == '\0' || *(str + length) == '/' ||  
~ *(str + length) == '\\') {  
  
~ *(str + length) = delim;  
~ }  
~ if (*(str + length) == '+') *(str + length) = '\xc2';  
~ }  
~ }  
- -----------/  
  
VMWare released the source code for their VMWare tools [8]which could  
allow to implement the same functionality by modifying the source code of  
official VMWare tools.  
  
  
*Report Timeline*  
  
. *2007-10-16*: Initial contact email sent to the VMware Security Team  
notifying discovery of a Priority 1 vulnerability in accordance to the  
vendor's security policy [9]. A draft security advisory describing the  
problem is available. Public disclosure of the vulnerability is scheduled  
on November 5th, 2007.  
. *2007-10-17*: Vendor acknowledges notification, provides public key and  
requests a draft of the security advisory .  
. *2007-10-17*: Core sends the draft advisory.  
. *2007-10-19*: Vendor indicates it will be able to address the issue in  
a release planned for December.  
. *2007-10-29*: Core requests an status update since there has been no  
communication since October, 17th, 2007. Vendor indicates it will be able  
to address the issue in a release planned for December, this information  
was already provided to Core on October 19th 2007 on a personal email  
exchange. The December release is likely to be move to the first week of  
January 2008.  
. *2007-10-29*: Core confirms that the December target was communicated  
on October 19th, 2007.  
. *2007-11-26*: Core requests an status update, asking if the vendor is  
still on track to release fixes in December 2007 and on which specific date.  
. *2007-11-26*: Vendor communicates that normally the release would be on  
December 27th, 2007 but since that date is in the middle of most people's  
holiday the release will be postponed to January. A specific date has not  
been set.  
. *2008-01-07*: Core requests and status update since there has been no  
communication since November 26th, 2007. Core asks if the vendor is on  
track to release fixes on the second week of January 2008. VMware had  
released of a new version of its VI product line in December but had not  
indicate if this release included fixed versions of the vulnerable VMware  
products. Publication of CORE-2007-0930 has been re-scheduled for January  
14th, 2007.  
. *2008-01-08*: Vendor communicates that none of the updates released in  
December 2007 addressed the vulnerability reported by Core and provided an  
official list of supported product that are vulnerable and their  
respective versions. Vendor cannot commit to a specific date for the  
release of fixes but can commit to release a fix within the first quarter  
of the year (Q1/2008). The upcoming release of minor version updates of  
vulnerable product is scheduled for February 14th.  
. *2008-01-08*: Email reply from Core indicating that publication of  
CORE-2007-0930 has been re-scheduled to February 14th., 2008. Nonetheless,  
the lack of vendor commitment to a specific date for the release of fixes  
does not make the ballpark commitment of Q1/2008 any more credible than  
the previous estimations.  
. *2008-02-06*: Core requests a status update since there has been no  
communication since January 8th, 2008. Core requests confirmation that  
VMware Server is not affected and asks if the vendor is on track to  
release fixes on February 14th. 2008 or on any other specific date within  
the first quarter of the year. In case that February 14th. 2008 was deemed  
not longer viable, Core will need notification by COB Monday January 11th,  
2008.  
. *2008-02-08*: Vendor response indicating that the release of new minor  
version updates to a subset of vulnerable supported products have been  
delayed and is now scheduled for February 24th., 2008. Minor version  
updates to another subset of the vulnerable products is planned for March  
15th, 2008. VMware Server is confirmed not-vulnerable since it does not  
provide Shared Folders functionality (HGFS).  
. *2008-02-08*: Core indicates that in view of the status update received  
from the vendor, publication of CORE-2007-0930 has been re-scheduled for  
Feb. 25th. 2008, this new date is still subject to change if and only if;  
i) Vendor confirms by Feb 13th. that the upcoming product releases planned  
for Feb. 25th. will indeed fix the bug. ii) Vendor commits by Feb. 13th.  
to a fix release date for the remaining set of affected products. iii)  
Vendor communicates any change to the Feb. 25th. release date by COB Feb  
20th. and the new release date does not exceed 6 working days from the  
currently scheduled date.  
. *2008-02-22*: Final draft of CORE-2007-0930 sent to VMware's Product  
Security Group. Any additional information to be included in the advisory  
should be received by COB Friday February 22nd.  
. *2008-02-25*: CORE-2007-0930 published.  
  
*References*  
  
[1] Top 5 Reasons to Adopt Virtualization Software -  
http://www.vmware.com/overview/why.html  
[2] "Ghost in the Virtual Machine", IEEE Security and Privacy, vol.5,  
no.4, pp.68-71, Jul/Aug, 2007  
~ http://doi.ieeecomputersociety.org/10.1109/MSP.2007.83  
[3] PaulDotCom Security Weekly - Episode #378  
~ http://www.pauldotcom.com/2007/07/31/escaping_from_the_virtualizati.html  
[4] iDefense VMware Workstation Shared Folders Directory Traversal  
Vulnerability (CVE-2007-1744)  
~ http://labs.idefense.com/intelligence/vulnerabilities/display.php?id=521  
[5] Microsoft Developer Network: MultiByteToWideChar  
~ http://msdn.microsoft.com/library/en-us/intl/unicode_17si.asp  
[6] VMware Workstation Release Notes  
~ http://www.vmware.com/support/ws55/doc/releasenotes_ws55.html#554  
[7] VM Back project  
~ http://chitchat.at.infoseek.co.jp/vmware/  
[8] Open Virtual Machine Tools  
~ http://open-vm-tools.sf.net  
[9]VMWare Inc. Security Response Policy  
~ http://www.vmware.com/support/policies/security_response.html  
  
*About CoreLabs*  
  
CoreLabs, the research center of Core Security Technologies, is charged  
with anticipating the future needs and requirements for information  
security technologies. We conduct our research in several important areas  
of computer security including system vulnerabilities, cyber attack  
planning and simulation, source code auditing, and cryptography. Our  
results include problem formalization, identification of vulnerabilities,  
novel solutions and prototypes for new technologies. CoreLabs regularly  
publishes security advisories, technical papers, project information and  
shared software tools for public use at:  
http://www.coresecurity.com/corelabs/.  
  
*About Core Security Technologies*  
  
Core Security Technologies develops strategic solutions that help  
security-conscious organizations worldwide develop and maintain a  
proactive process for securing their networks. The company's flagship  
product, CORE IMPACT, is the most comprehensive product for performing  
enterprise security assurance testing. CORE IMPACT evaluates network,  
endpoint and end-user vulnerabilities and identifies what resources are  
exposed. It enables organizations to determine if current security  
investments are detecting and preventing attacks. Core Security  
Technologies augments its leading technology solution with world-class  
security consulting services, including penetration testing and software  
security auditing. Based in Boston, MA and Buenos Aires, Argentina, Core  
Security Technologies can be reached at 617-399-6980 or on the Web at  
http://www.coresecurity.com.  
  
*Disclaimer*  
  
The contents of this advisory are copyright (c) 2008 Core Security  
Technologies and (c) 2008 CoreLabs, and may be distributed freely provided  
that no fee is charged for this distribution and proper credit is given.  
  
*GPG/PGP Keys*  
  
This advisory has been signed with the GPG key of Core Security  
Technologies advisories team, which is available for download at  
http://www.coresecurity.com/files/attachments/core_security_advisories.asc.  
  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1.4.7 (MingW32)  
  
iD8DBQFHwue1yNibggitWa0RAqOZAJoDkzrfyfJRPodprshHMvqqRju1QQCgqWmv  
NDbMYm9mdftFmDl+9Au/4pA=  
=P7zB  
-----END PGP SIGNATURE-----  
`