[TC 11.57a pre5] Security fix "prevent attacks by fake cmd.exe in current directory" not consistent

[white]

04.03.26 Release Total Commander 11.57 beta 2
04.03.26 Fixed: Command line: replace *cmd with cmd.exe in system32 directory, e.g. c:\windows\system32\cmd.exe, to prevent attacks by fake cmd.exe in current directory (32/64)

Yet, if you run *any_command using Shift+Enter, no such protection exists. For example:

Code: Select all

*echo 123

And doesn't the same risk exist when using cmd without the "*" and running Total Commander as administrator?

[ghisler(Author)]

What do you mean? When I run
*echo 123
with Shift+Enter, it starts noclose.exe/noclose64.exe.

[white]

with Shift+Enter, it starts noclose.exe/noclose64.exe.

Which in turn run cmd.exe in the current directory, also when elevated.

And doesn't the same risk exist when using cmd without the "*" and running Total Commander as administrator?

Do you have any comments on this?

[ghisler(Author)]

Which in turn run cmd.exe in the current directory, also when elevated.

I see - please try this updated noclose.exe/noclose64.exe, which explicitly calls GetSystemDirectory and also surrounds the path with double quotes.
https://plugins.ghisler.com/addons/noclose.zip

Do you have any comments on this?

The user already is at high risk when using Total Commander with full admin rights, so this is far from the only danger.

[white]

Which in turn run cmd.exe in the current directory, also when elevated.

I see - please try this updated noclose.exe/noclose64.exe, which explicitly calls GetSystemDirectory and also surrounds the path with double quotes.

Confirmed, also when not using * in front of the command. It makes more sense this way.

Do you have any comments on this?

The user already is at high risk when using Total Commander with full admin rights, so this is far from the only danger.

Which is why more protection is needed, which is why you implemented the fix mentioned in the first post.

[ghisler(Author)]

Which is why more protection is needed, which is why you implemented the fix mentioned in the first post.

No, I added the protection so users who care for security and run TC in non-elevated mode are protected from running the wrong command elevated. People who run TC elevated for certain tasks should know what they are doing, and not be restricted in their work.

[white]

Which is why more protection is needed, which is why you implemented the fix mentioned in the first post.

No, I added the protection so users who care for security and run TC in non-elevated mode are protected from running the wrong command elevated. People who run TC elevated for certain tasks should know what they are doing, and not be restricted in their work.

I'm not quite sure what your arguments are here exactly.

* You seem to imply that people who run TC elevated don't care about security and because of that they shouldn't be protected. I fail to see how people's feelings about security are relevant to your willingness to provide protection.

* You say people who run TC elevated should know what they are doing. You use the word ""should" here, which undercuts your argument. You seem to acknowledge that they very well may not know what they are doing.

* You seem to imply that if they are aware of the risk of typing "cmd" on TC's command line when running TC elevated, they shouldn't be protected. I fail to see how this is relevant to your willingness to provide protection. The risk is there nonetheless. Very knowledgeably people can still fall victim to a malicious cmd.exe program being executed. And when TC is run elevated, the changes of the system containing such malicious program seems greater.

* You seem to imply that if people are aware of the risk of typing "cmd" on TC's command line when running TC elevated, they are significantly restricted by not being able to run a program called "cmd.exe" in the current folder by using a command that starts with "cmd". It does not seem like a significant restriction to me for these experienced users to have to use (for example) "cmd.exe" instead of "cmd" in that case.

What exactly are your arguments?

[ghisler(Author)]

My argument is that people who run TC elevated need to be aware of the risk they are in. Every program they launch will be opened with admin rights, every file they open will be opened in a program with admin rights. Carelessly running a command from the command line without checking the environments is their responsibility. If I checked for cmd, next would be other commands. What about notepad? mspaint? powershell? There are many other such pitfalls.

Edit: Since it's only a small change, I will replace cmd with GetSystemDirectory() + cmd.exe also when not running it elevated. The user can still enter cmd.exe if they want to run it from the current directory.

[ghisler(Author)]

This has been changed in Total Commander 11.58 RC2, can anyone confirm it please? It doesn't matter whether you run TC elevated or not.
Steps to reproduce:
1. Copy notepad.exe to a new directory, e.g. to c:\test
2. Rename notepad.exe to cmd.exe in c:\test
3. In c:\test, enter command
cmd
in the Total Commander command line.
-> in older versions this would start the renamed notepad, in RC2 it starts cmd.exe from system32 instead.
4. Instead of cmd, enter the command
cmd.exe
in the Total Commander command line.
-> this will actually run the cmd.exe in the current directory.

[petermad]

Under windows 7, notepad.exe can not be executed unless it is run from c:\windows, c:\windows\system32 or c:\windows\SysWOW64

I tested with write.exe (copied from c:\windows\) instead, and can confirm the change in TC 11.58 rc2

[white]

Tested OK using TC 11.58rc2 32-bit and 64-bit.

Moderator message from: white » 2026-06-09, 12:56 UTC

Moved topic
» from TC11.x bug reports (English) to TC Fixed bugs