Comodo CIS Bug fix policy

[rashmi]

Get ready to roll your eyes... he's back in town with his shady pals - Irresponsible, Immoral, Delusional, Fanatic, and Garbage - spreading a toxic blend of misinformation, fabricated stories, and manipulated data about COMODO Firewall, the celebrated cybersecurity!

 

[Pico]

I'm referring to when it's a child process of unknown or malware, the svchost process is in Containment, virutalized and not allowed to connect out. e.g. running edge in the container which is a trusted file won't connect to the interenet if I don't allow it to via the firewall alert as below. If you change the Firewall Mode to Custom it will alert for every connection whether trusted or not .

Head scratching...
When I recall correctly in CS default settings FW is always on safe mode, why would a trusted file (like edge as you say) not be allowed to connect out in containment?
Am not talking about FW custom mode.

 

[bazang]

Get ready to roll your eyes... he's back in town with his shady pals - Irresponsible, Immoral, Delusional, Fanatic, and Garbage - spreading a toxic blend of misinformation, fabricated stories, and manipulated data about COMODO Firewall, the celebrated cybersecurity!

If @Decopi would make such derisive posts about VS in any Voodooshield discussion he would be banhammered. But since it is Comodo they are allowed to get away with it.

 

[Decopi]

Totally different from Comodo... Voodooshield:
1. It is an updated and upgraded software;
2. Very well maintained;
3. The developer is a serious, responsible and moral person;
4. Reported bugs are fixed;
5. Voodooshield never lies presenting itself "as the ultimate complete unbeatable security system";
6. Voodooshield always presented itself as a "blocker", and the software delivers what it promises;
7. Voodooshield users are normal persons, they are not emotionally attached to Voodooshield, criticism is not censored, there is no bullying, there is tolerance,
8. Voodooshield users are not fanatics, nor manipulators, nor irresponsible, they don't mislead other users, they don't try to convince other users to use Voodooshield;
9. Etc etc etc

In short, Voodooshield is the opossite than Comodo.

 

[ErzCrz]

Totally different from Comodo... Voodooshield:

In short, Voodooshield is the opossite than Comodo.

Part of the reason why I bought what ended up being 2 years worth though I could see me grabbing many more years of it. It's effective and I agree in all your points here about CyberLock/VoodooShield and you can set it to create WF block rules. CF runs along side it just fine though probably overkill. I do also like CL/VS with DefenderUI and WFC.

Both are default deny approaches though so I depends what works best for people.

 

[Pico]

If @Decopi would make such derisive posts about VS in any Voodooshield discussion he would be banhammered. But since it is Comodo they are allowed to get away with it.

Maybe they know that he has valid points, maybe not all points but certainly most of them.

 

[bazang]

In short, Voodooshield is the opossite than Comodo.

It is a paid software. VS has revenue that pays for the development. Comodo does not have revenue for the software.7. Voodooshield users are normal persons, they are not emotionally attached to Voodooshield, criticism is not censored, there is no bullying, there is tolerance,

7. Voodooshield users are normal persons, they are not emotionally attached to Voodooshield, criticism is not censored, there is no bullying, there is tolerance,

Oh please. VS threads are locked more often than any other discussions at this forum because neither the developer nor its users can handle criticism.

5. Voodooshield never lies presenting itself "as the ultimate complete unbeatable security system";

Nobody ever said that Comodo is the ultimate, unbeatable security system. It is you that are the problem here - your interpretation of what other people say. You do know that there are those that state VS is "bullet proof" or "virtually bullet proof," right? So if you want to talk about lies you should start right there.

8. Voodooshield users are not fanatics, nor manipulators, nor irresponsible, they don't mislead other users, they don't try to convince other users to use Voodooshield;

Sure thing. You do realize that the Voodooshield developer uses MalwareTips as his own personal marketing platform, right? The whole reason they are here is to promote the product and convince users to use it. LOL.

Try harder.

 

[bazang]

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.

 

[Behold Eck]

Comodo has HIPS so straight away it`s better protection than VS as this is a product that is only an A_E.

Regards Eck

 

[Chuck57]

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.

 

[Pico]

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.

 

[Chuck57]

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.

 

[wat0114]

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.

 

[Decopi]

@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.

It's not the protocol.
It's not the port.
It's the IP!

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).

As a simple illustration, when Comodo is used, Firefox is forced to use svchost for comms. Both, Firefox and svchost are whitelisted by Comodo (both are considered "safe"/"trusted"). Therefore Firefox has free comms through svchost to tons of IPs (just limited by protocol/port). Comodo doesn't filter Firefox IP comms (through svchost). Now, instead Firefox, let's place a virus/malware, and the same logic applies, if the virus/malware uses svchost for comms, it'll have access to tons of IPs (really it doesn't matter protocol/port, what matters is just the IP).

Always good to remember that svchost using DNS resolver (customized IP) doesn't stop comms to other IPs.

This is not a bug. This a design flaw problem, mainly because Comodo never evolved in the last 20 years.

Comodo Firewall is a placebo.

 

[ErzCrz]

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.

 

[cruelsister]

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.

 

[Pico]

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?

 

[Decopi]

Any sub process of a file in sandbox will not be allow to connect out without permission of the user.

At Comodo default settings, the Firewall is on "safe" mode, so no user here, it's automatic, Comodo uses an arbitrary list (not updated in 15 years) to identify what's "know"/"unknown"... that's all. And at Comodo the svchost is always identified as "safe"/"trusted", therefore at Comodo any file using svchost always will have free comms.

That said, if user changes Comodo default to "custom rules", "ask first", "deny all" or similar... then it becomes a nightmare, because in the best scenario an user can allow/block few apps, but 99,99% of the users never will know how to manage hundreds of Windows connections. Unfeasible and unreal! Not to mention that virus/malware connecting through svchost they will appear as requesting comms under the name of svchost, so 99,99% of the users will allow it.

Why then in my example in the Edge being safe not allowed to connect out.

It's important always to talk about real world!
Comodo is a blocker, and blockers in essence can block anything. However:
1. A blocking function is not an identification/detection of virus/malware
2 Blocking is a trade-off, as long as you block more and more, you will have less and less usability

That said, 99,99% of the users in normal world, if they use Comodo, then they will use "safe" settings, which means that Windows Services files, svchost, and a long list of another files... all them will have free comms. Therefore, if a virus/malware hijacks one of these "safe"/"trusted" files... then the virus/malware will have comms. Period.

PS: At Comodo (default settings) browsers work under several firewall rules, not just one rule. That said, not every browser uses svchost! It depends on the browser.

 

[Decopi]

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?

Comodo has several modules. Every module is expected to have a specific function. It's not valid to justify firewall design flaws but saying: "the firewall has no problems because the malware is running in containment".

Comodo firewall by default automatically uses "safe" rules, which means that Windows Services files, svchost and another hundreds of files, all of them will have free comms. And that's the problem! It's not a bug. It's a design flaw.

Regardless of whether a file is sandboxed or not, there are two problems here:

1. Windows Services files, svchost and hundreds of other files can't be customized at Comodo firewall
2. The Comodo "safe" list of whitelisted files... is a time-bomb.

PS: Please, allow me two questions:
a. Hypothetically, if everything is solved by sandboxing/containerizing stuff, then why firewall is needed at all?
b. If containment fails (and that already happened many times in the past), then how Comodo firewall will block virus/malware?

 

[cruelsister]

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.