Use short name path instead of long name path

Question

This month we came accross a vulnerability which is cause by installing patches with their environment path unquote and embedded space. (long path name).
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. 
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 use 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. 
So the question is..... since Windows 95, when creating a bin path both long and short path name are created if enable in the registry
For example lets take this example...
The OS will create enviroment variable for pointing to long path name  C:\Program Files\crapy.exe
and also create a short path name for C:\Progra~1\crapy.exe
So how can I tell WSUS to install the path and create a environment variable to point to the executable to use the short path name instead of the long path name? Is this possible?
Or I will have to create a report of software which install the updates patches with vulnerability and request a revision of the update.
Or should I go a head identify the services which are type auto (exclude disable, manual) and code a script program and modify the enviroment path... Consequences of this approach, will I need to re-run the script if there a new software update for the third
party software and it does n't address the path problem. I will need to run the script again.
Or should I create a policy and associate the script with it, until a revision comes along.
How can I get around this vulnerability as a long term fix versus a short term fix?
Can someone tell me the best approach (mitigate) to solve this issue?
thanks
michael john ocasio

Answer 1

This month we came accross a vulnerability which is cause by installing patches with their environment path unquote and embedded space. (long path name).
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.
I'm not sure I'd call this a vulnerability. It's how Windows has worked since long path names were created for Windows 95. If there's an embedded space in a pathname it has to be delimited. If you don't delimit it, unpredicatable results will occur -- but
most often a "File not found" error (if you're trying to read a file), or a "File creation error" if you're trying to create a file.
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”?
Yep. Although I suspect it's been a Very Long Time since anybody tried to launch Microsoft Word from the command line.
Or maybe you are trying to execute “C:\Program files\Microsoft.exe” and pass it the argument “Office\Winword.exe”?
Well, if you were, then you'd have to use the syntax as you've defined it -- with delimiters. But it's not a realistic example, given that executables don't belong in the root of the %ProgramFiles% folder anyway.
So how does it know what you are trying to do?
It's a computer. It's STUPID. It does exactly what you tell it to do ... nothing more, nothing less. The operator is the person responsible for intelligently instructing the computer to do what is desired to be done. (e.g. if you want to start a program
from the command line then use the right syntax!)
Can someone tell me the best approach (mitigate) to solve this issue?
I'll repeat my earlier thought: Use the correct syntax. :-)
Btw.... most developers don't hard code those pathnames anyway.. they use the SYSTEM ENVIRONMENT VARIABLES, e.g. %ProgramFiles%. Problem solved.
Other pathnames are typically stored in a registry value, and when the registry value is retrieved using API calls, the code, as a matter of habit, wraps delimiters around the string. Using delimiters when not needed is not a problem; not using them when
they are is a problem -- so -- the easy solution is to always use delimiters when you're defining pathnames in your code and you won't have a problem.
Lawrence Garvin, M.S., MCITP:EA, MCDBA, MCSA
SolarWinds Head Geek
Microsoft MVP - Software Distribution (2005-2013)
My MVP Profile: http://mvp.support.microsoft.com/profile/Lawrence.Garvin
The views expressed on this post are mine and do not necessarily reflect the views of SolarWinds.