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

berndgoetz commented 2 years ago

Purpose of the issue

[x] Bug report (encountered problems/errors)
[ ] Feature request (request for new functionality)
[x] 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:

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

Thanks.

berndgoetz commented 2 years ago

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 commented 2 years ago

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 https://github.com/cmderdev/cmder/issues/1959 and https://github.com/cmderdev/cmder/issues/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!