The following security advisory is sent to the securiteam mailing list, and can
be found at the SecuriTeam web site: http://www.securiteam.com
- - promotion
The SecuriTeam alerts list - Free, Accurate, Independent.
Get your security news from a reliable source.
http://www.securiteam.com/mailinglist.html
- - - - - - - - -
Path Traversal Vulnerability in VMware's Shared Folders Implementation
------------------------------------------------------------------------
SUMMARY
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.
DETAILS
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.
<http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1004034>
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>
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>
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>
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>
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>
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>
http://www.vmware.com/support/ws55/doc/releasenotes_ws55.html#554
[7] VM Back project <http://chitchat.at.infoseek.co.jp/vmware/>
http://chitchat.at.infoseek.co.jp/vmware/
[8] Open Virtual Machine Tools <http://open-vm-tools.sf.net>
http://open-vm-tools.sf.net
[9]VMWare Inc. Security Response Policy
<http://www.vmware.com/support/policies/security_response.html>
http://www.vmware.com/support/policies/security_response.html
ADDITIONAL INFORMATION
The information has been provided by <mailto:advisories@coresecurity.com>
Core Security Technologies Advisories.
The original article can be found at:
<http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2129>
http://www.coresecurity.com/index.php5?module=ContentMod&action=item&id=2129
========================================
This bulletin is sent to members of the SecuriTeam mailing list.
To unsubscribe from the list, send mail with an empty subject line and body to:
list-unsubscribe@securiteam.com
In order to subscribe to the mailing list, simply forward this email to:
list-subscribe@securiteam.com
====================
====================
DISCLAIMER:
The information in this bulletin is provided "AS IS" without warranty of any
kind.
In no event shall we be liable for any damages whatsoever including direct,
indirect, incidental, consequential, loss of business profits or special
damages.
