Startup calls: C:\WINDOWS\System32\find /i "\cmd.exe" which fails due to Avecto

[berndgoetz]

Purpose of the issue

• Bug report (encountered problems/errors)
• Feature request (request for new functionality)
• Question

Version Information

Cmder 1.3.19
Windows 10 with Avecto Whitelisting software

Description of the issue

At startup of Cmder, it calls the following command:

C:\WINDOWS\System32\find /i "\cmd.exe"

This command triggers our Avecto whitelisting security to block the call, or asks me for the Windows password to override and call it anyway. This is an Avecto policy setting.

Running the command without the backslash in front of the cmd.exe, i.e.:

C:\WINDOWS\System32\find /i "cmd.exe"

works without an issue.

Now my questions:

1. Where can I find the location where this command is triggered? I could not find it.
2. What's the purpose of this command? Could it be removed or fixed?

Thanks.

[berndgoetz]

Allright, I found the script that makes these calls, it's in vendor\lib\lib_base.cmd.

    echo %comspec% | %WINDIR%\System32\find /i "\cmd.exe" > nul && set "CMDER_SHELL=cmd"
    echo %comspec% | %WINDIR%\System32\find /i "\tcc.exe" > nul && set "CMDER_SHELL=tcc"
    echo %comspec% | %WINDIR%\System32\find /i "\tccle" > nul && set "CMDER_SHELL=tccle"

Removing that code removes the Avecto alert.

But one of my questions is still valid: What exactly are these commands supposed to do? When I run the first command manually, and I allow to run it, it takes forever. This can impossibly be the intent.

[DRSDavidSoft]

I'm not the developer, but I thought I'd chime in.

These commands are supposed to detect the currently running command line interpreter, which is most likely the cmd.exe provided by Microsoft, but could also be a product called TCC/LE from JP Software. It's an alternative to cmd.exe with more internal commands.

Now, the %comspec% variable points to the path of the ComSpec (i.e. the command line interpreter), such as this:

C:\WINDOWS\system32\cmd.exe

In order to detect this, we can pipe the output of this variable to the find.exe from Microsoft (i.e. echo %comspec% | find /i "\cmd.exe").

This will find the substring "\cmd.exe" in the comspec variable, and when present set the CMDER_SHELL to cmd.

Additionally, the full path to C:\WINDOWS\system32\find.exe is used, since there exists a variant of find.exe which is from the GNU/Linux project (e.g. Git for windows) with a totally different function, so if it takes precedent in the %PATH% variable, it will be ran instead of the Windows find.exe one.

As you can see, the \ in \cmd.exe shouldn't really make a difference since it's just a substring of C:\WINDOWS\system32\cmd.exe.

If you are not using the TCC/LE alternative command line interpreter, this shouldn't matter and you can safely edit the script to remove the \ -- however, the weird thing is that it should not matter in the first place.

This detection is being done to disable the clink shell and cmder aliases due to incompatibility with the TCC/LE software. (introduced in #1959 and #1806)

I'm not sure how Avecto parses the passed parameters to find.exe, but my best guess is that it detects the \cmd.exe as something to be executed (rather than being searched in the ComSpec variable).

As an alternative, we can parse the C:\WINDOWS\system32\cmd.exe string in order to manually extract the filename of the running comspec.

@echo off

set CMDER_SHELL=unknown

call :detect_comspec %ComSpec%

echo Cmder Shell is: %CMDER_SHELL%

goto :eof

:detect_comspec
	if /i "%~nx1" == "cmd.exe" set CMDER_SHELL=cmd
	if /i "%~nx1" == "tcc.exe" set CMDER_SHELL=tcc
	if /i "%~nx1" == "tccle" set CMDER_SHELL=tccle
exit /b 0

As an added bonus, this method doesn't rely on calling an external find.exe executable, which might be faster (and won't invoke security software by executing additional binaries).

Hope this helps!

[daxgames]

@DRSDavidSoft looks good to me. Will get it changed or as always PRs are welcomed!

[DRSDavidSoft]

@daxgames Awesome! I made a PR in #2744 although this is untested code. Will appreciate it if you could test it first and then merge it.

@berndgoetz hopefully this will fix the issue for you, as well.

[daxgames]

@DRSDavidSoft Amazing! I was just opening my laptop to do this. Testing now.

[daxgames]

@DRSDavidSoft Made a small change to fix and merged after testing.

@berndgoetz please test and let is know.

[DRSDavidSoft]

@daxgames Thanks for merging!

[daxgames]

@berndgoetz note build is failing right now so you will need to copy the file from Github into your current install.

[berndgoetz]

Guys, you rock! I've put the file into my current setup and it works like a charm! Thanks a lot! I leave it up to you to keep this issue open until the new release is out or you close it already now. Greetings.

[daxgames]

@berndgoetz thank you running Cmder on company managed systems has long been slow if not impossible for some so any improvement helps.

It is extremely difficult for us to fix these types of things because we do not have the system you have to replicate issues and test fixes. The fact you were able to narrow down to the line of code that was causing the issue was huge and makes our job easy.

@DRSDavidSoft thank you for the fix. I am not sure I would have come up with what you provided and I certainly would not have come to it so quickly. Much appreciated!

[DRSDavidSoft]

@daxgames Hey man, I appreciate all the efforts you do for the Cmder, and I'm glad to be of any kind of help regarding optimizing the code! 😄
@berndgoetz Thank you for tracking down the cause of slowness, it's awesome to figure out where the code slows down on certain machines.

Hopefully, if the issue is resolved now, we can close the issue. (I have some other PRs there also eagerly waiting to be merged! 😅 )