This is a critical request for urgent and immediate action(s).
I downloaded Process Hacker in order to test CIS capability for self protection and CIS failed miserably. Yesterday however, I downloaded Process Explorer from Microsoft Sysinternals and tried to kill CIS processes and CIS then succeeded to defend itself.
Today is a whole different story Process Hacker was able to kill both cfp.exe and cmdagent.exe.
CIS D+ gave me a warning that Process Hacker was trying to modify some registry key(s)
I unticked remember my answer and allow the file to completely execute.
Therefore, Process Hacker gui appeared on the screen.
I located CIS processes and right click; I selected kill and the processes were killed one after the other.
CIS was completely dead. I really do not know what’s going now. FYI I also tried Online Armor and I also killed Online Armor Processes with Process Hacker. However, One of Online Armor processes put up a fight I had to select Terminator from the list, and OA was dead. I’m quite scared right now. I thought CIS self-protection was impregnable.
Could some of you guys repeat the test and see If you could replicate the same results in order to verify my findings. Please.
Mayday, Mayday, Mayday. This is NOT a joke. The situation is extremely important.
Virtual System: VirtualBox
Operating System: Windows XP SP2
Software Installed: CIS 3.10 and Process hacker.
Host Operating System: Windows Vista SP1
Software Installed: CIS 3.10 Avira free.
It does selfprotect itself, all CIS exe’s can be killed by Process Hacker, but D+ loads into the Kernel so if you run a application D+ will Default Deny, in other words D+ cant be killed by shutting down cmdagent.exe or cfp.exe.
Oh and the firewall is kernel also, i have tryed this and killed cmdagent also, i tested it after and D+ and the FW where silent but both still doing there jobs.
The bottom line to me is that CIS processes were terminated, whether D+ loaded in kernels is irrelevant because D+ was not even able to protect CIS processes from termination. That’s a fact. Urgent action needed to build CIS defenses in order to succesfully protect its own processes.
I also think the the setting “Block all unknown requests if the application is closed” Should be considered as a tick box option when installing CIS so that more people use and are aware of it.
Thanks for the link. Am I to believe that Comodo is not interested in fixing the problem? Since the problem still exist. Or are they still working on a solution? The notion that CIS can always self protect its processes has been refuted. What’s next? A malware that will prevent CIS to load in kernel and then that will be the end of the computer security world.
And that’s precisely what I meant when referring to that link for Jaki
Tonight I feel really sad and depressed
Please don't be depressed.
When we are - our reaction to events in most cases are not very relevant (don't be offended. I said: "we"= "all of us" :) ).
What that discussion said, and what Dennise2 confirmed - that is not a real issue
Find the Registry Setting / startups / devices / drivers … disable basic protection or “allow” actions yourself and go ahead and disable / uninstall / devices/ remove /crash whatever you want… You do that - you will succeed.
When the “Alien Application” will try to perform that and you are not - alerted that would be a big concern… but that wasn’t the case.
You both missed the point here. By allowing it to run meant the software did not display any malicious behavior, it just ran. The malicious behavior occurred when Process Hacker terminated CIS processes; that was the point. D+ crumbled as if though it was built on sand.
When that happened D+ contingency plan kicked in and went to a default deny mode. All my ports were still stealth and I was not able to run anything, and that is good. However, my contention point is D+ did not protect its own processes and that needs to be rectified.
I just tested Agnitum Outpost Security Suite 2009 with Process Hacker even though I was able to terminate its gui process; however, I was not able to terminate its core process. I think the process name is acs.exe. When I tried to kill it, it went back up right away. That process simply would not stay dead.
Consequently, I proceeded to use Process Hacker Terminator and Outpost core process resisted the attempt to be terminated. Process Hacker failed to terminate it even though I allowed Process Hacker to do so after several warnings from OSS 2009 I might add.
To me it is essential that CIS, beside the contingency plan of default deny, be able to defend its processes successfully. If this is a bug, then it is a major one. I only hope that Comodo finds a solution to that problem soon.
On Windows 7 you cannot kill CIS’ processes via Taskmanager if D+ is working correctly what should be the normal case.
The option of D+ to block all unknown events if CIS is closed doesn’t provide more security because CIS will automatically enable such an option if it gets closed in a non usual manner, e.g. killing it with other processes such as Process Hacker.
If you deny Process Hacker to load it’s kernel mode driver it can’t kill CIS’ processes.
There can’t be protection anymore once a kernel mode driver is loaded.
Just a brief summary of everything one need to know regarding this issue here.
The warning that I got when I ran Process Hacker could be the same warning that I could get when I run other applications such as a download manager, a cleaner, a video player etc… There is no malicious behavior by running Process Hacker. However, when I initiated Process Hacker to terminate a process and successfully did so, that’s the malicious behavior. Can you deny that? Default deny is just a contingency plan after the fact. The fact is CIS processes were terminated.
You probably forgot that Process Hacker is not a rogue application. It is an application that allows someone to test his or her security apparatus. How can you really test a security apparatus if you do not allow the testing application to be fully loaded. If, for the sake of argument, Process Hacker was a piece of malware I would not even have allowed it to run, of course. Your screenshots of D+ blocking Process Hacker is beside the point.
I would consider success for CIS if it had blocked Process Hacker even after being fully loaded like Outpost Security Suite 2009 did. Please read reply #10. OSS 2009 did successfully prevented its core process from being terminated even when Process Hacker was fully loaded.
You stated also that: “There can’t be protection anymore once a kernel mode driver is loaded.” Well that is not true at least with respect to OSS 2009. Process Hacker kernel mode driver was indeed fully loaded and yet it could not terminate OSS 2009 core process. That is exactly the same thing I want CIS to do.
I was unaware of this thread until last night, consequently, it is not old to me ;D. However, I still have the same question what is being done about it? Are the engineers of Comodo still working on a solution?
Allowing a driver to be loaded mean that the driver will be able to obtain the same privileges/rights of the security software drivers.
As Process hacker developer noted, it would be possible to bypass any security using kernel drivers thus prevention ought to be carried by denying those drivers to be installed/loaded.
Whenever some other app may attempt to restart itself it is likely that a driver might be used to prevent this backup mechanism from occurring.
Though adding \Device\KprocessHacker to My protected files will provide a way to prevent termination, in order to use D+ properly it is important to be aware that driver install/loading should not be overlooked.
Indeed like for a termination driver it would unreasonable to allow a kernel rootkit and expect the system to be protected and this is the reason HIPSes focus on preventing these attempts…
