Comodo CIS Bug fix policy

bazang

Level 7
Jul 3, 2024
301
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).
 

Pico

Level 6
Thread author
Feb 6, 2023
266
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?
 

i7ii

New Member
Sep 3, 2024
7
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).
 

Antig

Level 2
Mar 23, 2021
57
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

cruelsister

Level 43
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 13, 2013
3,224
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.
 

Decopi

Level 8
Verified
Oct 29, 2017
361
The literature is abundant, it is very common to see a virus/malware hijacking the official SVCHOST signed by Microsoft. The same goes for other Windows Services.

In the case of Comodo, there is an accumulation of serious technical failures:

1. Comodo does not detect or identify virus/malware. Comodo is just a blocker, so Comodo puts the user at risk by forcing him to execute the virus/malware;

2. Once the virus/malware is being executed, it can easily hijack other executables, for example the official SVCHOST signed by Microsoft. I repeat, signed or not signed, at Comodo any "Safe"/"Trusted" file has free comms;

3. By default, Comodo labels as "Safe"/"Trusted" all the Windows Services, the Svchost, and hundreds of other files. It doesn't need to be signed! If the user or Comodo labeled a file as "Safe"/"Trusted", that's it, end of history, that file will have free comms. All "Safe"/"Trusted" files have free comms at Comodo. It's worth remembering that in the past, Comodo labeled executables (that were viruses/malware) as "Safe"/"Trusted". Those executables were not containerized/sandboxed, and Comodo Firewall gave them free comms. Again, this has happened in the past!;

4. Considering that Comodo does not allow the customization of firewall rules for these "Safe"/"Trusted" files, every virus/malware can hijack these files, and obtain comms;

5. Comodo is built in modules. The failure of a module (Firewall) cannot be justified by alleging that another module (Containment) avoids virus/malware comms. If Containment fails (and in the past it already failed many times), a virus/malware can hijack all the files considered "Safe"/"Trusted", and Comodo not only does not detect or remove that virus/malware, as worse, Comodo Firewall allows free comms for that virus/malware.

Comododo Firewall is a placebo.
 
Last edited:

Pico

Level 6
Thread author
Feb 6, 2023
266
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.
 

cruelsister

Level 43
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Apr 13, 2013
3,224
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).
 

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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"
 

Decopi

Level 8
Verified
Oct 29, 2017
361
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"

You're right. However, please allow me some clarifications:

As you know, at Comodo one module is the Containment, and another module is the Firewall.

Containment is a dumb blocker, based on a "known"/"unknown" list. Since that list has not been updated for 15 years, Comodo tends to block tons of valid executables. Still, it has been proven many times that Containment is vulnerable and can be bypassed. Even in the past, Comodo itself labeled as "known" (valid) executables that were viruses/malware, and obviously bypassed Containment. But as you rightly say, at first you expect a blocker, no matter how dumb it is, to block all files that are "unknown". And in this context, making a video showing a fake svchost ("unknown") blocked by Containment... makes no sense.

Now, the Firewall module in Comodo by default considers hundreds of files as "safe"/"trusted", allowing free comms. As you rightly say, C:\Windows\System32\Svchost is one of those hundreds of files considered "safe"/"trusted", therefore at Comodo it has free comms. Therefore at Comodo, a virus/malware can hijack svchost, and the Firewall will be bypassed. This is not a bug, it is a design flaw, because Comodo Firewall does not allow customization of "safe"/"trusted" files, and "safe"/"trusted" is an arbitrary outdated list of hundreds of files. Therefore, Comodo Firewall is a placebo.

In this context, it is a fallacy to make a video showing that Containment blocked a virus/malware, for three reasons:

1. With Containment disabled, the Firewall would allow the virus/malware to hijack svchost, and worse, the Firewall would allow free comms. No honest video can hide Comodo Firewall's flaw;

2. If the fake argument here is "Firewall worked because comms were containerized/sandboxed", then you can eliminate the Firewall because this fake argument implies that everything can be done just with the Containment;

3. With Containment enabled, if the virus/malware is blocked, it proves nothing about the Firewall!
Containment cannot tell you anything about the Firewall, that's a fallacy!

And even if a video shows a blocked virus/malware by Containment, that's a manipulation, because for every virus/malware blocked by Containment there are other viruses/malwares that are NOT blocked. No software is perfect, none blocks 100%, just as no antivirus/antimalware is 100% efficient. It's an irresponsible dishonest selective manipulation to show whatever Comodo Containment blocks, when there are always viruses/malware that are not blocked and can bypass Comodo Containment.
 
Last edited:

ErzCrz

Level 22
Verified
Top Poster
Well-known
Aug 19, 2019
1,169
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
 

rashmi

Level 12
Jan 15, 2024
551
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?
 

Antig

Level 2
Mar 23, 2021
57
I can take the definition of 'irresponsible' for using CF from super Decopi, I wonder how people who took the burden to test Comodo -among other things- will think about you when you imply they are all dishonest :
No honest video can hide Comodo Firewall's flaw

While I am still waiting to read a detailed Containment failure from you, I have to note that people clearly less obsessed than you were in te past banned or threads closed for manifest trollism.
 

Pico

Level 6
Thread author
Feb 6, 2023
266
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"
Is that rule included in one of the default Comodo CIS configs or was it added by user afterwards?
 

Pico

Level 6
Thread author
Feb 6, 2023
266
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).
Can't svchost be used by legit apps or abused by malware to connect out on IPv6?
 

wat0114

Level 13
Verified
Top Poster
Well-known
Apr 5, 2021
620
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. I

Thanks Erz, I will try this later after re-installing CFW.

@rashmi

yes, no alerts for IPv6 and connections also were established. I will try what @ErzCrz mentioned above.

@Decopi

I only ran CFW in safe mode temporarily, then I would delete the safe list and use my own customized containment and firewall rules. Some similarities in the containment setup to cruel's, and the firewall setup as being very restrictive, alerting to everything and requiring me to setup customized rules. Just how I wanted it.

@Pico

no that rule is just a snippet of the entire rule set for svchost.exe after I created my own customized firewall rules for it. It was taken from opening one of my *.cfgx backup rule sets using notepad.
 

Decopi

Level 8
Verified
Oct 29, 2017
361
yes, no alerts for IPv6 and connections also were established.

At Comodo, IPv6 is an old unfixed bug since 2017, many and many times reported at official Comodo forum... another bug among around other 500 accumulated bugs.

@Decopi

I only ran CFW in safe mode temporarily, then I would delete the safe list and use my own customized containment and firewall rules. Some similarities in the containment setup to cruel's, and the firewall setup as being very restrictive, alerting to everything and requiring me to setup customized rules. Just how I wanted it.

You can use Comodo or whatever you want. You are free to use and you have the right to use whatever you want.
I'm only saying that what's good for you might be bad, wrong and dangerous for 99,99% of the users.

Deleting the safe list will not solve Comodo Firewall design flaw. That's because you're going to have files and apps requesting the use of Windows Services, or Svchost, or another files. And Comodo Firewall doesn't allow to customize these files. For example, At Comodo Firewall you can make general rules for svchost, but you can't make specify rules when svchost is used by X.exe or Y.exe. So in this example, at your new safe customized list you are going to label "svchost" as "safe"/"trusted"... and then you will have exactly the same problem that Comodo Firewall default settings have with the original safe list.
There is no solution to the Comodo Firewall design flaw.
Comodo Firewall is a placebo.

PS: Windows Firewall and many other third-party firewall software allow the complete customization of almost any file.
 

Chuck57

Level 12
Verified
Top Poster
Well-known
Oct 22, 2018
590
I can take the definition of 'irresponsible' for using CF from super Decopi, I wonder how people who took the burden to test Comodo -among other things- will think about you when you imply they are all dishonest :


While I am still waiting to read a detailed Containment failure from you, I have to note that people clearly less obsessed than you were in te past banned or threads closed for manifest trollism.
Well, i, too, am one of the irresponsible, dishonest, manipulative non-experts. I just put the new CF back on this computer. I like Portmaster, found that it did work well, but I feel better with Comodo Firewall protecting me. So, henceforth I'll answer to liar, dishonest and being a manipulative knuckle dragger
 

rashmi

Level 12
Jan 15, 2024
551
@rashmi

yes, no alerts for IPv6 and connections also were established. I will try what @ErzCrz mentioned above.
My ISP offers native IPv6 and prioritizes it over IPv4.

I use Comodo Firewall Proactive Security: default containment settings, disabled HIPS, and enabled firewall safe mode and IPv6 filtering. Also, I block incoming connections. I have disabled Windows Firewall and Defender through Group Policy, and I don't use any other security software.

Comodo Firewall's safe mode allows connections for trusted programs. I have HideAway VPN, which uses IPv6 to check for updates. I marked HideAway and Chrome as unrecognized in CF File List and ran both, with CF containment enabled and disabled. In both cases, Comodo Firewall showed alerts for IPv6 connections. I tested with both stealth mode settings: blocking incoming connections and alerting incoming connections. I didn't create any rules in Comodo Firewall's global rules.
 
Last edited:

ErzCrz

Level 22
Verified
Top Poster
Well-known
Aug 19, 2019
1,169
If youo enable logging in the global rule you'll see the IPv6 blocks in the case below, blocking neighbourhood solicitation and a second image of some start=up blocks while CF was loading.

If your running full stealth you'll need to create allow rules for ICMPv6 - Packet too big, time exceeded, ICMPv6 type 135 type 0 & 136 type 0 for router advertisement and neighbour solicitation for IPv6 to work properly but that's from old notes.

1726078435641.png


1726078620510.png

1726078379900.png

Anyway,, use what works for you. Time to go and see if I can identify the apparent 500 accumulated bugs.
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top