The Microsoft Windows API includes the CreateProcess() function as a
means to create a new process and it's primary thread.
CreateProcessAsUser() is similar but allows for the process to be run in
the security context of a particular user.
The format of the CreateProcess() function is as follows:
The 'lpApplicationName' variable contains the name of the module to be
executed. However, this can be a NULL value, in which case, the module
name to be executed will be the first white space-delimited token in the
It is a known issue, that if lpApplicationName contains a NULL value and
the full module path in the lpCommandLine variable contains white space
and is not enclosed in quotation marks, it is possible that an alternate
application will be executed. Consider the following scenario:
c:program filessub dirprogram.exe,
In this case, the system will successively expand the string when
interpreting the file path, until a module is encountered to execute.
The string used in the above example would be interpreted as follows:
c:program.exe filessub dirprogram name
c:program filessub.exe dirprogram name
c:program filessub dirprogram.exe
Therefore, if a file named program.exe existed in the c: directory, it
would be executed instead of the intended application. This is a known
issue, discussed directly in the API documentation:
Despite the fact that this is a known issue, several popular
applications, insecurely call the CreateProcess() and
CreateProcessAsUser() functions. This creates a scenario whereby
arbitrary code could be executed. In the scenario detailed above, if an
attacker were able to install arbitrary code in a file at
c:program.exe, when the vulnerable application was launched, the code
would be executed. The arbitrary code would generally be executed under
the privileges of the executing user but could also be launched with
elevated privileges if an insecure call were made CreateProcessAsUser()
using elevated privileges. This attack would involve some form of social
engineering or need to be combined with another attack to first get the
arbitrary code installed in the correct location.
The following applications have been confirmed to be vulnerable:
Application: RealPlayer 10.5
Application: Kaspersky Anti-Virus for Windows File Servers 5.0 (English) - Installation File
Application: iTunes 184.108.40.206
Application: VMWare Workstation 5.0.0 build-13124
Application: Microsoft Antispyware 1.0.509 (Beta 1)
Note: The vulnerability in Microsoft Antispyware was previously
discussed on the Full-Disclosure mailing list
but remains unpatched.
Ensure that unexpected files are not stored in locations that can be
used for this attack. Windows XP SP2 will alert a user of the existence
of a file named c:program.exe when it first boots, however, any path
containing white space where a vulnerable application is stored could be
used in this attack.
The following vendor responses have been provided.
"Due to the way iTunes 5 launches its helper application, multiple
system paths are searched for which program to run. This may allow a
malicious user on the local system to create an environment where an
alternate program will be executed by iTunes. iTunes 6 addresses this
issue and can be obtained from http://www.apple.com/itunes/download/.
Credit to iDEFENSE for reporting this issue to us."
"We are currently looking into the problem, and it seems that this is
not present in the current version of KAV for File Servers."
"Microsoft has confirmed that the Beta 2 version of its Antispyware
product, targeted for release later this year, will address the issue
reported by iDEFENSE."
The Common Vulnerabilities and Exposures (CVE) project has assigned the
following names to this issue.
RealNetworks RealPlayer 10.5
Kaspersky Anti-Virus 5.0
Apple iTunes 220.127.116.11
VMWare Workstation 5.0.0 build-13124
Microsoft Antispyware 1.0.509 (Beta 1)
Theses are candidates for inclusion in the CVE list
(http://cve.mitre.org), which standardizes names for security problems.
09/19/2005 Initial vendor notification
11/15/2005 Coordinated public disclosure
The discoverer of this vulnerability wishes to remain anonymous.
Get paid for vulnerability research
Free tools, research and upcoming events
Copyright © 2005 Verisign, Inc.
Permission is granted for the redistribution of this alert
electronically. It may not be edited in any way without the express
written consent of iDEFENSE. If you wish to reprint the whole or any
part of this alert in any other medium other than electronically, please
email firstname.lastname@example.org for permission.
Disclaimer: The information in the advisory is believed to be accurate
at the time of publishing based on currently available information. Use
of the information constitutes acceptance for use in an AS IS condition.
There are no warranties with regard to this information. Neither the
author nor the publisher accepts any liability for any direct, indirect,
or consequential loss or damage arising from use of, or reliance on,