Path Traversal vulnerability in VMware's shared folders implementation **Core Security Technologies - CoreLabs Advisory** ### 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 All versions of VMware's desktop products that include the Shared Folders feature up to: * 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 Workstation 6.0.3 * VMWare Workstation 5.5.6 * VMWare Player 2.0.3 * VMWare Player 1.0.5 * VMWare ACE 2.0.3 * VMWare ACE 1.0.5 * 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 ; 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. * **2008-03-18: **VMware VMSA-2008-0005 security advisory and corresponding fixes 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 - [3] PaulDotCom Security Weekly - Episode #378 - [4] iDefense VMware Workstation Shared Folders Directory Traversal Vulnerability (CVE-2007-1744) - [5] Microsoft Developer Network: MultiByteToWideChar - [ http://msdn.microsoft.com/library/en-us/intl/unicode_17si.asp]() [6] VMware Workstations Release Notes - [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: [](). ### 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 [](). ### 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. ### PGP/GPG Keys This advisory has been signed with the GPG key of Core Security Technologies advisories team, which is available for download at /legacy/files/attachments/core_security_advisories.asc.

Query Builder