excluding all Winsshd executable files from buffer overflow protection, using Defense plus settings ~ Image execution control ~ exclusions. This now excludes from guardxx.dll
defining all Winsshd executable files as installer/updaters in the computer security policy ~ defense plus rule
check you have not got ‘block all requests when the application is closed’ under Defense plus setting ticked
Reboot after making all the above settings and re-try Wsshd
If this does not work, please make a bug report in the standard format referred to in the stickies. Please link in the previous topic - or I will if you like.
Hopefully it will work. But if not the new system means that we will track the solution to this bug better.
After several tries, I managed to run a version of “WinSSHD 5.09” and “Comodo 5” … but as with the version of “Comodo 4 or 5” it is impossible to run the version “WinSSHD 5.19”
If someone comes to thank you for sharing his “setup”
Did you use the steps 1-4 I suggested above to run WinSSHD? If it was not easy to understand I can try to explain by PM. Even in French if you can bear with my bad grammar!
I just do the test with the version “WinSSHD 5.19” (the last) and it does not work.
I will still stay with my version of “WinSSHD 5.09” that works (maybe in version “Comodo 6”, this will be corrected)
With “Outpost Firewall Pro 7.0 x64” the latest version of “WinSSHD 5.19” works without problem, but I do not use it …
THanks very much Steph, a very good issue report, and your English is fine.
Just one query on the report: what is you CIS configuration? Just right click on the CIS tray icon to find it.
Also could you try two more tests. One to help me find out whether guardxx.dll exclusion is actually working in CIS 5. One to just to check it’s defense plus that is the problem.
Please could you:
Disable Avast to the maximum extent possible, then reboot and re-try WinSSHD
Tick disable defence plus permanently, then reboot and re try WinSSHD. Then untick this, and reboot.
Rename guard32.dll (32 bit system) guard64.dll (64 bit system). You’ll find them in Windows\system32. Then reboot. Retry WinSSHD. Then rename guardxx.dll back to the original name and reboot - or keep it renamed if it works - but remember that your security level will be reduced if you do.
Then I’ll send it across to verified reports and give it a tracking ID
Disable Avast to the maximum extent possible, then reboot and re-try WinSSHD
OK, Avast uninstalled → Winsshd still does not
Tick disable defence plus permanently, then reboot and re try WinSSHD.
;D Winsshd 5.19 works perfectly !
Then untick this, and reboot.
does not
Rename guard32.dll (32 bit system) guard64.dll (64 bit system). You’ll find them in Windows\system32. Then reboot. Retry WinSSHD. Then rename guardxx.dll back to the original name and reboot - or keep it renamed if it works - but remember that your security level will be reduced if you do.
I renamed “guard64.dll” to “guardxxx.dll”, reboot → ;D Winsshd 5.19 works perfectly !
There … I prefer to have “WinSSHD 5.09” that works without removing protection in “Comodo” that use “WinSSHD” 5.19" with optional protections removed in “Comodo”
Problem is solving by adding c:\windows\system32\cmd.exe to exclusion of Buffer overflow protection (D±>D+ Settings->Execution control settings->Exclusions)
SwissSteph confirmed me in PM, what after adding cmd.exe to BO exclusions SSHD 5.19 works fine with CIS.
Thanks very much, it would be very helpful to our work helping users if you could explain a) why this works b) whether it is safe for users more generally to do this.
a) Described issue is probably caused by a specific functioning of SSHD. When we launch a remote terminal, it seems that SSHD performs injection operation to cmd.exe (e.g. launching cmd.exe as virtual user), which is blocked by CIS.
b) I think it doesn’t cause any serious problems concerning user’s safety, because D+ in any case will protect cmd.exe from activity of unrecognized application and show an alert.
does not