Maximus said:
Spoken like a true Comodo supporter HeffeD. Default/Deny everything including faults in CIS. Thanks for that helpful yet meaningless reply. As far as the logs go. What if someone who did not understand what was going on? They would flip out. No matter how you look at it Logitech software is NOT malicious. SetPoint is doing nothing wrong therefore there is no reason to set off a flag in the logs. But not listening to users input and addressing issues such as this has always been the Comodo way and will never change. Once thanks HeffeD for reassuring why I will never is a Comodo product or recommend it to my customers. Good companies listen the public and adapt accordingly. But Comodo thinks opposite. Comodo wants the customer to adapt to there product. When in doubt blame the other guy. That kind of attitude towards customers is why CIS will never surpass NIS or KIS.
On another note I will stress that CIS, more so D+ is a very good product in the hands of a knowledgeable user.
Nobody is saying that Logitech is malicious. Merely that Setpoint is trying to access CIS processes in memory, and CIS blocks and logs this access. That's as far as it goes.
And no, this isn't a false positive. CIS is merely reporting what is happening. It's a bit like the people reporting a false positive in regards to a buffer overflow alert. (an actual alert, not just a log entry) Sure, the application may not be malicious, but it
is causing a buffer overflow, which could be exploited. The only "fix" in this instance is again, having the developer of the application take a closer look at that code to pinpoint what is causing the buffer overflow.
I have to say that I'm somewhat surprised at your cavalier attitude towards an application trying to access your security applications processes in memory. Or better yet, why you feel that application should be able to...
I do like CIS, but I'm definitely not a fanboy. And if there's a problem, I would expect it to be fixed.. This however, isn't a problem. It's merely CIS saying, "someone tried to touch my naughty square, I didn't let them"...
I feel this is a completely appropriate response from a security application!
Nothing needs to access my security applications processes in memory.
Comodo
does listen to the public and acts accordingly. In fact, just in the last couple of weeks, Egemen has personally done remote testing on two users computers to see what is going on with something they've reported. (One of these users is even running 5.9 as a result of the testing (and fixes), which the mods don't even have yet...)
If you report a problem to Symantec, will the lead developer of NIS remotely access your machine to personally check it out? I somehow doubt that.
I'm sorry if you feel I'm not being helpful. I just don't happen to see a problem with CIS adding a log entry that it blocked an interprocess memory access.
I see more of a problem with the fact that Setpoint is trying to access the process of a security application in memory. Why is it trying to do this?