Help eliminate unquoted path vulnerabilities

Published: 2012-11-07
Last Updated: 2012-11-08 04:05:52 UTC
by Mark Baggett (Version: 1)
19 comment(s)

Metasploit’s “Service Trusted Path Privilege Escalation” exploit takes advantage of unquoted service paths vulnerability outline in CVE-2005-1185, CVE=2005-2938 and CVE-2000-1128.    The vulnerability takes advantage of the way Windows parses directory paths to execute code.   Consider the following command line.

C:\windows\system32\notepad \temp\file.txt

This tells windows to launch notepad.exe from the c:\windows\system32\ directory and pass it the argument \temp\file.txt.    The result is notepad.exe will execute and begin editing file.txt from the temp directory.    How does Window’s differentiate between the program and the arguments?  The SPACE is used as a delimiter between the program to execute and the arguments.   Now consider this command line.

C:\program files\Microsoft Office\Winword.exe

If space is used as a delimiter, wouldn’t Windows think you are trying to execute the program  C:\PROGRAM.EXE and pass it the argument “files\Microsoft Office\Winword.exe”?    Or maybe you are trying to execute “C:\Program files\Microsoft.exe” and pass it the argument “Office\Winword.exe”?  So how does it know what you are trying to do?    If the software developer places quotation marks around the path then Windows knows the spaces are spaces and not delimiters.   If the software developer fails to put the path in quotes then Windows just doesn’t know.  If Windows doesn’t know then it tries to execute all the possible programs in the path.  First it tries “C:\Program.exe”,   Then, it tries “C:\Program files\Microsoft.exe” and finally the path we intended for it to execute.    

This programming error is very common because when a developer is addressing paths on the file system they are usually stored in strings.   Because they are in strings the developer has used quotes once already and they often fail to consider that they need two sets of quotes.  For example, the following line would incorrectly assign the path variable.

pathvariable = “C:\Program Files\Common Files\Java\Java Update\jusched.exe”

Really, the developer needs to double quote it because they need the path to contain quotes.  So they should have assigned their variable by doing something like this:

pathvariable = “\\”C:\Program Files\Common Files\Java\Java Update\jusched.exe\\””

In the first case, an attacker can strategically place a program in the path and his program will be executed instead of the intended program.   If the process runs under administrative privileges or some account other than the attacker it can be used to cause code to execute under a different set of privileges.  

We have known about these types of vulnerabilities for 12 years now.  So much so, that if you create a file called c:\program.exe Windows will generate this pop up when you reboot the machine.

With such an old vulnerability, surely very few programs suffer from this problem, right?  You might be surprised at how often this vulnerability occurs.     So let’s start fixing it!    This is an easy problem to identify.    Here are some steps you can follow to identify applications that fail to quote their file paths directly.    Then you can help fix this by contacting the vendor to have them fix these issues.

First you need to copy any existing executable and create a program named c:\program.exe.   For example, take a copy of calc.exe and name it c:\program.exe.   Then make a copy of calc.exe named c:\program files\common.exe.  Last, create a copy of calc.exe called c:\documents.exe.    Then go about your business and use your computer as you normally would.    Sometime while you are running normal applications they will accidently launch the renamed calc.exe.   System reboots, services and scheduled tasks may trigger calculator.    Whatever the cause, eventually you will likely run a vulnerable program and it will launch the application on your computer.   Several days may transpire between the time you create the files and the time they are executed.   Remember you did this when you have strange copies of calc.exe spontaneously launching on your computer.   Once one your copy of calculator executes, first find out which one of your calc.exe programs launched and who launched it.    Use WMIC to query which copy of your calculator is running like this.

Here you can see this query for “program.exe” returns the command line that was executed when our executable launched.   This program failed to properly quote the system paths and launched your renamed program.    Often times you may be able to identify the vendor responsible for the software from just the command line that launched your program.     But often times it is also useful to know the parent process that launched the command line that started your program.   To find out what program launched the unquoted path we use the following commands.

There you go bug hunter.  You found a 0-Day vulnerability!  Now notify the vendor so they can patch it and keep everyone safe.  While you are at it you can notify us if you would like.

Join me in San Antonio Texas November 27th for SANS 504 Hacker Techniques, Exploits and Incident Response!  Register Today!!

Follow me on Twitter @MarkBaggett
Mark Baggett

Update: Here are some additional references.  Thanks to altonius for the links and

19 comment(s)


but if "In the first case, an attacker can strategically place a program in the path and his program will be executed instead of the intended program." aren't all bets off anyway? As I see it, the attacker being able to place any program anywhere is the bigger vulnerability.
This vulnerability is used to either persist malware on the remote host or for a privilege escalation exploit. Certainly, as you point out, you don't want the attackers to be able to put anything on your hard drive. But an attacker uses this vulnerability to do things like this.

This problem wouldn't exist if that flawed trial-and-error logic wasn't applied to begin with.Developers wouldn't be able to use unquoted paths since it just wouldn't work. With the current model unquoted paths works 99.99% of the times during development and QA.
Thanks for the useful suggestion. I tried it and had a calc window pop up almost immediately. I'll point the responsible vendor to your article.
In my profile root folder I have a copy of notepad.exe renamed to rundll32.exe, and on my desktop I have a copy of calc.exe also renamed to rundll32.exe. This leads to surprising and interesting results.

For example, if I right-click on my (XP SP3) desktop an choose "New" then "Shortcut", notepad starts.

Note: in registry key "HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\" I have the value "CWDIllegalInDllSearch" set to 0xFFFFFFFF, which helps to prevent some "path" related vulnerabilities, but may cause existing applications to fail.

@G: agreed, applications such as web browsers should not drop binaries in unexpected directories. However such vulnerabilities have existed and may still exist. For example, Apple had to be convinced that dropping binaries on the users desktop was not a good idea (Google: safari carpet bomb).
Default NTFS permissions for a new volume allow new files and folders to be created by unelevated users at the root, such as your C:\Program.exe. We mitigate against this on our system images by removing those special permissions on the C: volume, which also prevents users from saving data outside their profile or installing software without administrative rights.
I am missing something. Doesn't this just tell you what was invoked, not what does the invoking? For instance, I got a hit on "C:\Program Files (x86)\Java\jre7\bin\java.exe -D__jvm_launched=<snip>". Ok great, but I don't know which process tried to start Java. Isn't that where the unquoted string lies, not in Java?
ha ha ignore that, I didn't make it all the way to the bottom of the diary
Also take a look over at to see an article on how to quickly identify services that may be affected. Found a couple of common hardware manufacturers services that use unquoted paths for their services.
Altonious. Thanks for that link. That is an excellent post. There is another really good post on the internet as well that talks about using this technique for malware persistence. I saw it about a month or so ago and it inspired this blog post. I tried to find that blog to give them credit, but haven't been able to find it. I remember the blog author started out by lamenting over the fact that this was a new attack to him even though it had been around for a while. If anyone knows a link to that other blog please post it in the comments. I'd like to give them some credit.

Diary Archives