Problem with launching programs from current directory

[ghisler(Author)]

Seems like different Windows functions (e.g. ShellExecuteEx, WinExec, CreateProcess) use different search paths. TC uses these functions depending on whether parameters need to be passed, or the process handle is needed or not.

[reflex]

How explains the search path, why TC does not look first in the current directory?

I cant find any info about that - still waiting for a link.

In contrast i provide here a link concerning search path:
http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/path.mspx?mfr=true

Please note the sentence:

The operating system always searches in the current directory first, before it searches the directories in the command path.

[MVV]

Please read here. You're talking (and reading) about console (i.e. cmd.exe), but it acts in another way than Windows itself... In fact, standard Windows function ShellExecute reads App Paths before than tries to search file in current directory. It may be explained by fact that Windows itself doesn't designed to have working directory in contrast to TC and console where current directory is necessary attribute.

[karlchen]

Hello, Christian. Hello, reflex.

As you, reflex, were right that I had not fully (or not at all) grasped the nature of the problem , I had a closer look at the old thread, Starting firefox in C:\Program Files instead of... and in particular at HolgerK's explanation which he got from a blog post on how the priority of

1. respecting qualified filenames
2. looking in the current folder
3. looking in the %SystemRoot% folder
4. looking in %SystemRoot%\System32 folder
5. following the search path
6. querying the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths

should be when ShellExecute() is used to launch an executable file.

... a call to ShellExecute, which I guess is not too surprising. The next thing I wanted to find out was exactly how the commands are resolved. The following is an ordered list of how they are resolved ([1]):

* The current working directory
* The Windows directory (no subdirectories are searched)
* The Windows\System32 directory
* Directories listed in the PATH environment variable
* The App Paths registry key
...

As you can see (highlighted in orange colour), I dared prefix respecting qualified filenames as having the highest priority.
I.e. if a user tells T.C. to launch "C:\utils\various\redhat.exe", then T.C. is supposed to launch "C:\utils\various\redhat.exe", no matter where else redhat.exe may be found and no matter what the regkey "App Paths\redhat.exe" may tell.
I.e. if a user tells T.C. to launch ".\redhat.exe", then T.C. is supposed to launch ".\redhat.exe", no matted where else redhat.exe may be found and no matter what the regkey "App Paths\redhat.exe" may tell. And if redhat.exe cannot be found in the folder ".", current folder explictly named, then T.C. is supposed to complain that ".\redhat.exe" cannot be found.
To the best of my knowledge and as far as I can tell from my tests, T.C. does respect qualified executable filenames.


Testing scenario:

Software environment:

Windows Vista Home Premium, SP2, 32-bit
Total Commander 7.55a

Executable file to be launched: redhat.exe
Copies of redhat.exe exist in
+ C:\Temp
+ C:\utils\Notepad2 (%PATH% contains this folder)
+ C:\utils\various ("App Paths\redhat.exe" points to this location)

Expectation:

Unless the current working folder is one of the 3 folders which have been named above, simply telling T.C. to launch redhat.exe should always find and launch C:\utils\Notepad2\redhat.exe, because this location is part of the %PATH% variable, and following the %PATH% should be done before consulting the "App Paths" regkey.

Note:

It was made sure that all 3 programmes, cmd.exe, Total Commander and Explorer.exe had the same environment including the %PATH% which also listed the foldername C:\Utils\Notepad2.

cmd.exe:

"redhat.exe" (without the double quotes) is launched from outside any of the 3 folders, listed above:
cmd.exe follows the %PATH% and launches C:\utils\Notepad2\redhat.exe.
If C:\utils\Notepad2 is removed from the %PATH%, cmd.exe will not find redhat.exe.
cmd.exe ignores the regkey "App Paths\redhat.exe"

"redhat.exe" (without the double quotes) is launched from C:\temp: C:\temp\redhat.exe is launched.
I.e. cmd.exe looks in the current folder first.

explorer.exe

"redhat.exe" (without the double quotes) is launched from outside any of the 3 folders, listed above by typing "redhat.exe" (without the double quotes) in the address bar:
explorer.exe reads the regkey "App Paths\redhat.exe" and launches C:\utils\Various\Redhat.exe.
I.e. Explorer gives a higher priority to "App Paths" than to the %PATH% variable.

"redhat.exe" (without the double quotes) is launched from C:\temp: C:\temp\redhat.exe is launched.
I.e. Explorer gives a higher priority to current folder than to "App Paths".


Total Commander:

"redhat.exe" (without the double quotes) is launched from outside any of the 3 folders, listed above by typing "redhat.exe" (without the double quotes) in the commandline:
T.C. reads the regkey "App Paths\redhat.exe" and launches C:\utils\Various\Redhat.exe.
T.C. gives a higher priority to "App Paths" than to the %PATH% variable.

"redhat.exe" (without the double quotes) is launched from C:\temp: C:\utils\Various\Redhat.exe is launched.
I.e. T.C. gives a higher priority to "App Paths" than to the current folder.

".\redhat.exe" (without the double quotes) is launched from C:\temp: C:\temp\Redhat.exe is launched.
I.e. T.C. gives the highest priority to qualified filenames.


Summary:

Explorer seems to follow this order:

1. respect qualified filenames
2. look in the current folder
3. query the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths
4. look in the %SystemRoot% folder
5. look in %SystemRoot%\System32 folder
6. follow the search path

Total Commander seems to follow this order:

1. respect qualified filenames
2. query the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths
3. look in the current folder
4. look in the %SystemRoot% folder
5. look in %SystemRoot%\System32 folder
6. follow the search path

I.e. compared to the Windows Explorer Total Commander seems to swap priorities (2) current folder and (3) App Paths.

Note:

Currently, I cannot check whether priorities (4), (5) and (6) really apply. %windir% and %windir%\system32 are the first two items in the %PATH% variable on all my Windows systems.


Suggestion:

Should T.C. not make sure it sticks to the same order as Explorer?
Maybe it would be even better to lower the priority of "App Paths" to be last in the list. (as it appeared to be according to the quoted blog post)
It is debatable whether checking "App Paths" before "%PATH%" is more likely to allow malicious manipulations than checking "%PATH%" before "App Paths".

Kind regards,
Karl

[karlchen]

@karlchen: Can you provide some links?

Please, see here: PerceivedTypes, SystemFileAssociations, and Application Registration section titled Application Registration.

This MSDN article had been linked to indirectly in the old thread. Just go to the blog post mentioned there: http://weblogs.asp.net/whaggard/archive/2004/04/11/111232.aspx and inside the blog post follow the link [1].

Kind regards,
Karl

[reflex]

@karlchen: thanks for the links - but in both of them "The current working directory" is listed at first position - i thought you have a link where the apppath comes before the current directory (as you mentioned at the start of the thread). But i am happy, that you are aware of the problem now and you are no longer on devils side


I hope this bug will be finally fixed - he survived at least over 2 years now (maybe with the help of a big portion of ignorance?).

[karlchen]

Hello, Reflex.

I assume that the problem could survive unaddressed for two years, because it will be noticed under particular conditions only:

• You launch an executable file at the T.C. commandline (or using a T.C. button) by giving the unqualified executable filename only. E.g. redhat.exe. (plus)
• You have got at least two different versions of redhat.exe on your disk. (plus)
• For the redhat.exe which you want to launch there is no entry in the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths (plus)
• For the other version of redhat.exe which you do not want to launch at this point in time, there is an entry in the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths

Only if all of these conditions are fulfilled you will notice that T.C. checks the regkey "App Paths" before looking in the current folder and before following the search path %PATH%.

It quite seems that all readers of the MSDN article had the impression that the API function ShellExecute() will try to find an executable file in this order, if it is launched by giving the filename only:

1. looking in the current folder
2. looking in the %SystemRoot% folder
3. looking in %SystemRoot%\System32 folder
4. following the search path
5. querying the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths

So it seems as if looking in the current folder should be done first, and looking at the registry key "App Paths" should be the last try, after all else has failed.

As your own experience, other posters' tests and my own tests suggest, neither Windows Explorer, nor Total Commander seem to stick to the order given above.

Windows Explorer seems to follow this order:

1. looking in the current folder
2. querying the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths
3. look in the %SystemRoot% folder
4. look in %SystemRoot%\System32 folder
5. follow the search path

Total Commander seems to follow this order:

1. querying the registry key HKLM\Software\Microsoft\windows\CurrentVersion\App Paths
2. looking in the current folder
3. look in the %SystemRoot% folder
4. look in %SystemRoot%\System32 folder
5. follow the search path

The questions are:

• Should the order given in the MSDN article be considered obligatory?
• Should the order followed by Windows Explorer be considered obligatory?
• Why does T.C. proceed in yet another order?
• Will T.C. be changed to follow either the order given by the MSDN article or the order followed by Windows Explorer?

Kind regards,
Karl

[reflex]

well, in your msdn link it says:

The order that those locations are searched varies, though the App Paths key is preferred in Windows XP Service Pack 1 (SP1).

The only logical solution is, that it works like cmd/explorer.
(and this is not inconsistent with msdn)

[sqa_wizard]

Thank you Karl for listing the differences in a clear way !
I prefer the Windows Explorer order too.

1. use current folder (this is what I can see directly)
2. use App Paths (this is a named reference)
3. use other search possibilities

[ghisler(Author)]

It may be very dangerous to change this now, just search for "application planting" or "dll planting" about the problem.

[Balderstrom]

I don't find anything relevant with a "application planting" search, and "dll planting" primarily discusses the unlikelyhood that a user can be tricked into the numerous steps it takes to cause it to work.

As well it's MORE likely malware could change the registry for what file should be launched with "firefox.exe" and TC would be enabling that exploit by refusing to execute the current folders "firefox.exe" in lieu of some obscure registry setting that the user has absolutely no clue about.

[reflex]

It may be very dangerous to change this now, just search for "application planting" or "dll planting" about the problem.

ATOMROFL!
Sure, i heard also about some terrorists planing to plant a bomb into TC *ggg*
TC behaves unpredictable cause this is a security feature (sic!) - very clever!

At least - despite of this awkward bug - its very amusing here!

[karlchen]

Hello, reflex.

Ad dll planting

DLL planting is a pretty old problem which has been discussed only lately, although first alerts about the problem are 12 years old and although e.g. David LeBlanc warned in his blog article DLL Preloading Attacks two years ago.

Cf. also this MS knowledgebase article: A new CWDIllegalInDllSearch registry entry is available to control the DLL search path algorithm

When investigating the DLL planting problem, it became apparent that executable files suffered from the same problem: application planting.

Ad application planting

The problem of EXE planting has been discussed lately: cf. e.g. Binary Planting Goes "EXE".


From my point of view, it is really debatable which functionality makes it easier for malware to fool someone into launching another executable file than he thinks he does

• searching any executable file which has been named without prefixing a pathname in the current working folder
  (On Linux/Unix systems the current folder will not be searched unless explicitly listed in the $PATH variable. - Personally, I would not mind if Windows adopted this behaviour.
  Either you willingly add . (dot) to your %PATH% or the OS will not look for executable filenames in the current working folder. If you add . (dot) to your %PATH%, then you should know what the consequences may be.
  You are always free to launch an executable located in the current folder this way: .\executablename.exe)
• getting the fully qualified pathname of an executable file which has been named without prefixing a pathname from the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths, provided an applicable entry having the name of the exectuable file exists

Microsoft created the "App Paths" registry key and recommended its use long before the current discussion about "application planting" and "DLL planting" started.

The reason for using "App Paths" entries is pretty simple and pragmatic:

In the ancient days of DOS almost any application added its own programme folder to the search path %PATH%.
One thing is that the maximum length of the PATH variable is limited.
Another thing is that in the end having extremely long search paths is inefficient and slow. You waste a lot of time searching for the same executable files in folders where they do not exist, in particular if the right folder is at the end of the PATH variable.
Getting the fully qualified executable filename by querying the registry key HKLM\Software\Microsoft\Windows\CurrentVersion\App Paths\filename.exe is much faster.


Now, back to Total Commander:

From my point of view it should be made sure that Total Commander respects the same order of search location as Windows Explorer whenever it has to locate and launch an executable file for which no path specification has been given.

Kind regards,
Karl

[reflex]

Here is a little autohotkey script as workaround, until this stupid bug gets fixed.
But currently the author says:"It's a feature, not a bug!" instead of "Sorry for any inconvenience - problem will be fixed asap",
so it will maybe never happen...

Code: Select all

;------- workaround TC bug - current directory is NOT first in search order!
;------- current path will be injected before first token
;------- tested with TC 7.55a (older versions may use different control names)
;------- http://monschein.org
#NoEnv
#NoTrayIcon
#SingleInstance force
#ifwinactive, ahk_class TTOTAL_CMD
Enter:: 

ControlGetText, sIn, Edit1
if (sIn != "")
{
	ControlGetText, sPath, TMyPanel3
	
	if (substr(spath,0) = ">")
		spath := substr(spath,1,-1)

	if (substr(spath,0) != "\")
		spath := spath . "\"
	sIn = %sIn%
	sIn := sIn . " "
	
	if (substr(sIn,1,1) = """") {
		sin := substr(sIn,2)
		fn := substr(sIn,1,instr(sIn,"""") - 1)
	}
	else {
		fn := substr(sIn,1,instr(sIn," "))
		stringreplace, sIn, sIn,%A_SPACE%,"%A_SPACE%
	}
	if (FileExist(spath . fn)) {
		snew := """" . spath . 	sIn
		ControlSetText, Edit1, %snew%, ahk_class TTOTAL_CMD
		sleep, 20
	}
}
Send {Enter}

Edit: removed trim/rtrim (only available in lexikos ahk build)
This script is enough for me - if it doesnt work for you: dont use it or change it.

[karlchen]

The easiest way of making sure that an executable file is launched from the current folder is by prefixing .\ to the executable filename.

Example:

.\notepad2.exe

will make sure that the notepad2.exe is launched which lives in the current folder, independent of
+ regkey "App Paths"
+ search path %PATH%