|
|
|
|
| |
Credit:
The information has been provided by Core Security Technologies Advisories.
The original article can be found at: http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2129
|
| |
Vulnerable Systems:
* VMWare Workstation version 6.0.2
* VMWare Workstation version 5.5.4
* VMWare Player version 2.0.2
* VMWare Player version 1.0.4
* VMWare ACE version 2.0.2
* VMWare ACE version 1.0.2
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 translate to a dot-do 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.
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
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
|
|
|
|
|
