Comodo CIS Bug fix policy

Maybe they know that he has valid points, maybe not all points but certainly most of them.
Valid points about what? Some of his points would be valid if he acknowledged that the Comodo has a revenue of $0, and therefore, that is the reason for its state of development.

As far as bugs and "bypasses," nobody that criticizes the product has ever legitimately shown that it fails to protect. All you people do is run your mouths about bugs. Whereas @cruelsister demonstrates over-and-over that Comodo protects. She has produced over 15 years of indisputable video evidence.

What is mostly going on here at MalwareTips is @Decopi and a few others are butthurt over @cruelsister posting her videos here. That is what the Comodo hate at this forum is mostly about.

The more people that attack @cruelsister, the more she is to be encouraged to keep doing what she does.
 
Valid points about what? Some of his points would be valid if he acknowledged that the Comodo has a revenue of $0, and therefore, that is the reason for its state of development.

As far as bugs and "bypasses," nobody that criticizes the product has ever legitimately shown that it fails to protect. All you people do is run your mouths about bugs. Whereas @cruelsister demonstrates over-and-over that Comodo protects. She has produced over 15 years of indisputable video evidence.

What is mostly going on here at MalwareTips is @Decopi and a few others are butthurt over @cruelsister posting her videos here. That is what the Comodo hate at this forum is mostly about.

The more people that attack @cruelsister, the more she is to be encouraged to keep doing what she does.
Many years of tests with CF, including some malware she coded that exists nowhere else. It has all been stopped by the firewall.

What I'm curious about with Comodo is Xcitium. They have a free version but I'm not familiar enough to know what it covers. It would seem to me Xcitium must be under development. I know the anti Comodo crowd will spam Xcitium the same as Comodo but from all I've read it works as well or better some of the others.
 
What I'm curious about with Comodo is Xcitium. They have a free version but I'm not familiar enough to know what it covers. It would seem to me Xcitium must be under development. I know the anti Comodo crowd will spam Xcitium the same as Comodo but from all I've read it works as well or better some of the others.
Comodo version and Xcitium version use same code, Xcitium has more features but don't expect the base code being better than Comodo.
 
Comodo version and Xcitium version use same code, Xcitium has more features but don't expect the base code being better than Comodo.
Just curious. I watched several YouTube things where Xcitium's endpoint finished ahead of Malwarebytes, ESET, and equaled a couple of others. No malware got to the machine. It was the HIPS and containment features that caught most of it although the AV surprisingly didn't do that badly.
 
Svchost is a system trusted service (executable) it could connect out in containment in FW safe mode, perhaps I'm missing something.

@ErzCrz post #339 is correct, especially the last sentence of the first paragraph. If, for example, you use Custom firewall ruleset and you decided to create two rules for svchost.exe,:

Allow Out TCP to Remote Port 443
Allow Out UDP to Remote Port 53

It will only be allowed to connect out to these two specific ports and those protocols and absolutely nothing else. The exact same principles apply to any other process, whether it be a Comodo Trusted process or not. The key is to use "Custom Ruleset".

EDIT

of course any IPv6 attempts will be allowed because of the related bug.
 
Last edited:
At Comodo, any "safe"/"trusted" file, sandboxed or not, restricted or not, containerized or not etc... regardless the protocol, and regardless the port... Comodo will always allow that file to have comms to tons of IPs.

That problem at Comodo has no solution because "safe"/"trusted" files, for example in the case of svchost, it is impossible to customize by IP (hundreds of files use svchost for comms, with thousands of different IPs).

At Comodo, the same problem happens with all the files considered "safe"/"trusted", which includes Windows Services and a long list of other files (not just svchost).

Therefore, at Comodo any virus/malware using, for example, svchost, will have comms to tons of IPs, regardless the protocol and the port. At Comodo, a virus/malware using svchost for comms, it can use any protocol and any port, because the virus/malware only cares about the IP... and at Comodo the svchost is free to connect to tons of IPs. Comodo can't stop comms for a virus/malware using svchost (or any other "safe"/"trusted" file).

Any sub process of a file in sandbox will not be allow to connect out without permission of the user. Why then in my example in the Edge being safe not allowed to connect out. I will try and find an example for you when I get time as I have to get to work but @cruelsister can clarify as it's been shown in her Data Stealer tests with CF where her data isn't leaked unless she allows the connection. It's not that complicated, I don't think.
 
Any sub process of a file in sandbox will not be allow to connect out without permission of the user. Why then in my example in the Edge being safe not allowed to connect out. I will try and find an example for you when I get time as I have to get to work but @cruelsister can clarify as it's been shown in her Data Stealer tests with CF where her data isn't leaked unless she allows the connection. It's not that complicated, I don't think.
The svchost.exe file is essential for the operation of Windows. Important things to note that a legitimate svchost file is SIGNED by Microsoft and resides in System32 (for 64-bit Windows). Also, it will never attempt to connect out by itself, but Child processes will utilize it to connect out’ but note that these child processes can be either legitimate or malicious.

Regarding Comodo, if Edge (signed and valid) utilizes svchost (signed and valid) to connect to the Net, Comodo will trust both and thereby the connection will be allowed without a peep from Comodo.
However, if a malicious (or unknown) file uses legitimate svchost, Comodo will react on the basis of the CHILD process (that’s why the Data stealer was flagged and stopped from connecting out to malware Command).

There is also the possibility that malware can create a fake svchost (NOT signed) and plop them anywhere on the drive. Such a file will blend in with other running svchost’s in Task Manager so the infective process more or less blends in quite well.

Again, for Comodo, any direct connection out by the mimicked svchost will be prevented as the fake will be regarded as Untrusted (coincidentally my next video-not about Comodo- contains such a malicious process).

Hope this clarifies a bit.
 
So, when malware is running in containment and tries to connect out by using svchost (either the real System32 one or a fake one) then Comodo FW (with FW set to safe mode) will always show a svchost FW alert when svchost tries to connect out. Is this correct?
 
So, when malware is running in containment and tries to connect out by using svchost (either the real System32 one or a fake one) then Comodo FW (with FW set to safe mode) will always show a svchost FW alert when svchost tries to connect out. Is this correct?
No- If a malicious file tries to connect out (using svchost) the FW alert would be for the Child process and not svchost itself (remember that svchost will never connect out by itself, thus no alert for the legitimate executable).

On the other hand, malware can masquerade as svchost (unsigned) and in this case an alert for svchost will be given. This weekend will be a Worm doing just that and bypassing the protection of the anti-malware application highlighted.
 
The svchost.exe file is essential for the operation of Windows. Important things to note that a legitimate svchost file is SIGNED by Microsoft and resides in System32 (for 64-bit Windows). Also, it will never attempt to connect out by itself, but Child processes will utilize it to connect out’ but note that these child processes can be either legitimate or malicious.

Regarding Comodo, if Edge (signed and valid) utilizes svchost (signed and valid) to connect to the Net, Comodo will trust both and thereby the connection will be allowed without a peep from Comodo.
However, if a malicious (or unknown) file uses legitimate svchost, Comodo will react on the basis of the CHILD process (that’s why the Data stealer was flagged and stopped from connecting out to malware Command).

There is also the possibility that malware can create a fake svchost (NOT signed) and plop them anywhere on the drive. Such a file will blend in with other running svchost’s in Task Manager so the infective process more or less blends in quite well.

Again, for Comodo, any direct connection out by the mimicked svchost will be prevented as the fake will be regarded as Untrusted (coincidentally my next video-not about Comodo- contains such a malicious process).

Hope this clarifies a bit.
This is how other security software firewalls work as well. They are no different than Comodo. Furthermore, most will not monitor legitimate svchost instances for code injection, for reasons that should be obvious to everybody here. There are only a few instances where AV will monitor for an attack on a svchost process, but nevertheless the firewall behavior remains the same for ALL security software under all circumstances - maliciously injected or not = those security software are not going to block legit svchost processes. Security software rely upon Microsoft's own built-in memory protection mechanisms to safeguard the integrity of legitimate svchost processes.

The person who keeps making the same argument about Comodo and "trusted" processes in an attempt to poison it here at MT is willfully, irresponsibly, and immorally misleading readers by not stating and explaining the facts for ALL security software.

The Comodo troll spreading misinformation by omission in an attempt to dissuade people from using Comodo via creation of fear, uncertainty, doubt (FUD).
 
No- If a malicious file tries to connect out (using svchost) the FW alert would be for the Child process and not svchost itself (remember that svchost will never connect out by itself, thus no alert for the legitimate executable).

On the other hand, malware can masquerade as svchost (unsigned) and in this case an alert for svchost will be given. This weekend will be a Worm doing just that and bypassing the protection of the anti-malware application highlighted.
In one of your videos malware runs in containment and tries to connect out using svchost. In that video I didn't see a malware FW alert but only a svchost FW alert for trying to connect out. What is different here?
 
It is a free product with $0 revenue.

So how much should Melih spend to fix bugs? $100,000? $1,000,000? The correct answer for a product with $0 revenue is "Melih should spend as close to $0 as he determines as the product owner."

People are lucky Comodo is willing to have any staff to participate on the forum.

No software publisher is going to spend the money to fix all kinds of bugs on a 100% free product, that is not subsidized by paying consumer subscribers.

Comodo could have 8,987,493,857 bugs and, yet still, millions of people will use it because it is free.

That would make sense in a world - where there's only Paid Application and Free Abandonware. But there's also such thing as Open Source Freebies and Freeware (closed source - but still free and active projects). Point being, if he gave up on that project - either make it open source (like many others did with their own outdated or non profiting passion projects) or say his goodbyes even kill it or just let it fade into virtual dust. Yet, this dev is doing neither - quite the opposite... playing pretend by including it in a supposedly active project with build names you'd see on future beta releases (adding a 2025 at the end - for a product released in 2024), not to mention the shady marketing:

2024-09-10_190210.jpg

...where this is suppose to be "a paid feature (or at least - a core feature which makes the Paid AV worth it compared to Free version). While at the same time... it's unofficially (or officially - if you visit the COMODO forum) - treated as abandonware - as if the dev itself doesn't seem know what to do with it "beyond the empirical evidence (old bugs ported from one version to next for years) - where actions is what truly label it as abandonware in... a werid state: part of a an active project - while also having a hardcore fan base - which in a way (taking into account real life similarities) - gives COMODO Firewall a religious status... an app which thrives on the strong belief of its followers alone. Also, based on same similarities with real life religions - pointing out core flaws in its design (like the huge bugs list - many quite old) - can anger its followers - as if attacking their religious belief (a heresy).

That being said... and based empirical evidence (actions - not words) - this project needs a clear label. Even if it's regarded as a new religion, that too is ok in 2024. But then (if that's the case) - it doesn't belong among all the other "FREE" Active Firewall projects "WHERE ACTIONS SPEAK FOR THEMSELVES (Fixed Bugs, New Features Added, etc)". Just because it's free - does not mean it's worth treated with same respect (like all the other alternatives which are truly active projects) - just because it comes with a 2025 label (playing pretend) - so that alone should make it worth a new topic (or multiple in across the year in question).
 
Unfortunately, its mediocre CEO (hated by his employees)
I wanted to quit this thread,but read it again instead and noticed that the the quoted phrase by the famous Decopi is exceptionally relevant in depicting the fact he seems to know a great deal of what really happened in the past 20 years at Melihs headquarters,he must have a really deep insight into things inside Comodo entourage.
He knows for sure that people working with the CEO in reality hate the guy.
I wonder,did he spend time with CEO and his programmers and workers ? Or did he receive this crucial info by a third person?
Something happened to really upset the Decopi to the point of cultivating a huge grudge towards the CEO and his associates and products?
But,if this was really a personal situation, why not saying so straightaway? People would have understood.
We would have spared hours of reading useless crap.
 
  • Hundred Points
  • Love
Reactions: rashmi and kylprq
In one of your videos malware runs in containment and tries to connect out using svchost. In that video I didn't see a malware FW alert but only a svchost FW alert for trying to connect out. What is different here?
The difference would be in utilizing svchost (allowed) vs a file mimicking svchost (not allowed as it is not the true svchost) to connect out. If you have the desire to watch this weekend's video and would like to see how CF would have handles things (as both legit and mimicked svchost can be seen), please let me know.
 
The difference would be in utilizing svchost (allowed) vs a file mimicking svchost (not allowed as it is not the true svchost) to connect out. If you have the desire to watch this weekend's video and would like to see how CF would have handles things (as both legit and mimicked svchost can be seen), please let me know.
I've taken a closer look at the related video. I had to zoom-in on the screen on the low-res video to see what actually was going on in containment. Indeed it was a file mimicking svchost (a fake non-Microsoft and Comodo rated untrusted svchost file) running in containment that caused the fake svchost FW alert.
Am curious what would have happened if the real Microsoft svchost was being utilized to connect out.

I believe we all want to see your new video, please conduct the real svchost test and fake svchost test both in FW safe mode and both on IPv4 and IPv6, thank you.
 
I believe we all want to see your new video, please conduct the real svchost test and fake svchost test both in FW safe mode and both on IPv4 and IPv6, thank you.
The first video will show the fake svchost connection, but the utilization of legit svchost will not be as, once again, svchost will never connect directly out (and these would just show up minged among the other svchost's that you currently have running. video 2 will show both with the legitimate svchost requests being detailed in Containment.

As for ipv6, this is not applicable for either video as neither shows a RCE attack from outside (fun fact- seems MSFT fixed the buffer overflow vulnerability last month with the 38063 patch).
 
Again, for Comodo, any direct connection out by the mimicked svchost will be prevented as the fake will be regarded as Untrusted (coincidentally my next video-not about Comodo- contains such a malicious process).

It should also be prevented by a path other than C:\Windows\System32. Because in the .cfgx file:

Code:
<Rules />
</PolicyItem>
<PolicyItem UID="{63870DEE-7851-4E34-A024-59F76402B328}" Flags="0" Filename="C:\Windows\System32\svchost.exe"
 
Just a side note. CF has IPv6 filtering disabled by default. If you enable it, you need to re-run the Stealth Ports Wizard under Tasks>>Firewall. In the case of Proactive configuration, it's Stealth Ports are set to Alert Incoming. The Global Rule ICMPv6 to block rule is then added to the list.
1726038862513.png
 
Just a side note. CF has IPv6 filtering disabled by default. If you enable it, you need to re-run the Stealth Ports Wizard under Tasks>>Firewall. In the case of Proactive configuration, it's Stealth Ports are set to Alert Incoming. The Global Rule ICMPv6 to block rule is then added to the list.
What is the issue with CF IPv6? No firewall alert for IPv6 connections? Rules not functioning?