none
Use short name path instead of long name path

    Frage

  • 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

    Samstag, 26. Januar 2013 22:31

Antworten

  • 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.



    Donnerstag, 31. Januar 2013 14:17

Alle Antworten

  • 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.



    Donnerstag, 31. Januar 2013 14:17
  • Thank you so much

    michael john ocasio

    Samstag, 2. Februar 2013 07:01