Does option ‘Block all unknown requests if the application is closed’ work for Windows System applications group (like svchost, services etc.)? I changed Predefined Policy from Windows System applications to Trusted applications for them to check this and rebooted computer, but Comodo didn’t block unknown requests from them while cfp.exe didn’t fully load.
because svhost and services where still running?
All works and blocks when I just close cfp.exe, but when I turn off and then turn on the computer, Сomodo can’t block unknown executables which have been launched by parent system applications while it is initializing.
It took me some searching but this is what egemen, the head developer, says about this setting:
I hope that my computer is free from any malware, and I use this option for extra security.
In help for CIS is written about it:
So, I deleted all Defense+ Rules, selected this option and rebooted my PC. I expected to see blue screen, but my computer worked normally and all system applications loaded as usually without any rules for them. Also all non-system services were loaded (tested on XP SP3).
P.S. I think this option must work when computer is booting and CIS is still not running… Am I wrong or is it a bug?
[attachment deleted by admin]
I tried it on XP SP3 in my vm. I don’t think it is a bug. Almost all Windows system files in XP are digitally signed and on the TSV list so they would be allowed during boot. They would not be allowed to start other applications. But apparently that is not a big issue when booting. See attached D+ logs.
[attachment deleted by admin]
Well, all unknown applications run in sandbox. This is good. But I do not use autosandbox because I want to see all alerts and to decide myself what action to allow, and what doesn’t. But in this case my computer is not protected and any unknown application will run. Is it good? ???
I tested again with the sandbox disabled. CIS does block programs that start before cfp.exe during boot. F.e. the client of CTM 2.9 beta did not start.
If your system does not block unknown programs during boot with the option ‘Block all unknown requests if the application is closed’ enabled then there is something wrong with the configuration or installation of CIS.
To see if it is problem with your configuration please import one of the factory default configurations, activate it and try again with the new configuration.
The factory default configurations can be found in the CIS installation folder. When importing you need to give it a name. Give it an appropriate name like f.e Proactive Security Clean.
Let us know if that fixed the problem for you or not.
EricJH, I tested many times with the new Internet Security configuration but unfortunately it didn’t give any results.
I don’t have CTM so I don’t know how it starts, but I have noticed that Comodo blocks all unknown programs which started from
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run
and from
Startup Folders,
but doesn’t block from
HKLM\System\CurrentControlSet\Services
and from
Task Scheduler
May I ask you to do another test whitout Sandbox? Just create bat file with this lines (or download it from attach)
start %windir%/system32/calc.exe pauseThen add this file to Task Scheduler and schedule task at startup. After rebooting you will see calc.exe in Windows Task Manager...
[attachment deleted by admin]
First an apologie. When I tested in my vm I had the Proactive Security policy active. So I did the test again and got the same results. See attached image.
Then I did the test you asked for with the batch file. I added two lines to make it different and therefor unknown to the cloud. This is the batch file used:
start %windir%/system32/calc.exeIn my case the batch did get sandboxed. See first attached image.
pause
echo hello
pause
When I disabled the sandbox it got run where other programs were blocked from booting like from VM Ware and Comodo Time Machine (ctmtray). See second image.
Now I am going to think a bit more on how to interpret this but I wanted to share my findings first here with you.
[attachment deleted by admin]
Services are apparently excluded from the application block. I don’t know why but I think that would cause too much problems when doing that.
As to the reason why Scheduled Tasks is excluded I can only guess.
However the Services keys in the registry are protected keys. It is very hard to circumvent that protection. As far as I understand are the tasks for Task Scheduler not stored in the registry but in c:\windows\Tasks. That is a protected folder and such not accessible for untrusted programs.
In short, even when scheduled tasks are run during boot with the “Block all unknown requests if the application is closed” setting enabled you are still protected because tasks are in a protected area.
If you find malware that can go around that protection you will always find Comodo interested in that and will fix it.
EricJH, I understand that scheduled tasks and services are under the protection of Defense+ and to write there unknown files or registry keys without the consent of the user impossible. But suppose that the user have allowed such action without knowing of the danger. If a virus is located in archive, the antivirus does not see it in real time. After rebooting, the virus will unzip and get full control over the system! You can say that the antivirus will catch it after unpacking, but it won’t! Antivirus doesn’t work (like Defense+ without Sandbox), until Comodo is not fully initialized (I wrote about it here).
If developers of Comodo have planned that this option would not block all unknown requests, but only partial, then why in helping is written that Defense+ blocks all of them? Do they deceive users?
Regular users would normally have the sandbox enabled and would be safe.
Switching to D+ only is something for a more advanced user who of course also could make mistakes. Of course running a HIPS like D+ can be unforgiving to user errors but I don’t know if this behaviour has changed over time since say v3.14.
Since I don’t know the exact ideas behind this I sent a pm to egemen, the head developer asking for an explanation. He is still on his honeymoon so we need to wait for his reply.
I disagree with this statement. I did some more tests. If you run an unknown service from HKLM\System\CurrentControlSet\Services, it is not blocked and the sandbox does not process it after rebooting.
Seems to me this may be worthy of a Bug report. Do you agree Eric?
If you do one we would be grateful if you could do so in standard format.
Many thanks
Mouse
With the sandbox enabled it is not possible to make an autorun entry for a service. That means that regular users are protected with default settings.
How did the unknown service get added to the autoruns of services? CIS will allow you to make such an entry yourself or was there a rogue action by an application that should have such rights? CIS is the nanny of program behaviour and not the nanny of user behaviour. In short the user is allowed everything including stupid and dangerous things which unknown programs are not allowed.
Egemen comments the following on CIS not blocking all autoruns during boot with “Block all unknown requests if the application is closed” enabled:
Its not going to block everything in any case. The users can mess with policy easily and lock up their systems.
When CIS set up instead of another antivirus and autoruns entries is already exist.
Its not going to block everything in any case. The users can mess with policy easily and lock up their systems.I did not say about [b]blocking all[/b]. I told about [b]non-system unknown[/b] applications, which Comodo doesn't block, and which can't lock operating system if they are not running.
Interesting. But the role of this setting is supposed to be to block autoruns when the system is known to be infected, presumably including infection due to user error or prior infection. So maybe the usual argument re user errors should not apply to this setting? It sure would be nice if there was a CIS setting that blocked all but essential Windows services & programs on reboot, while the infection is dealt with say by Geekbuddy. But maybe we have to await integration of some bits of CCE for this sort of thing. Meanwhile the documentation should probably make it clear that protection is partial.
Probably should flag up a GUI/help text issue… but maybe not a bug then…
Mouse