Add Option To Cloud AV to stop launch of new executable until classified [M981]

1. What version of CIS, or Comodo Firewall, are you currently using:
Comodo Firewall 7.0.313494.4115

2. What actually happened or you saw:
When I launched an unknown executable it was allowed to run, Cloud AV then about a second later alerted me about the file and claims it’s malware however the program is still allowed to run.

Current Timeline:

[ol]- Run unknown executable.

  • It’s allowed to run | Cloud AV also starts analyzing the file.
  • Cloud AV alerts about the file claiming it’s malware | The executable is still allowed to run.[/ol]

3. What you wanted to happen or see:
If there is a working connection to the Cloud servers then the Cloud AV should block any unknown executable from launching until the Cloud AV has gotten the results from the cloud. (If Cloud AV can not communicate with the servers, or it times out after a reasonable time, then allow the file should be allowed to run)

Of course this should be an option and not forced!

Suggested Timeline:

[ol]- Run unknown executable.

  • Cloud AV should temporarily block the unknown executable from running.
  • If the executable is found to be safe then allow it to run. | If the executable is found to be malware by Cloud AV then keep blocking it and display alert.

[li]If user chooses “Clean” then clean it.

  • If the user chooses “Ignore” then let the executable run.
    [/li][/ol]

Example of how the option could look like and how the help file could look like:


4. Why you think it is desirable:
It’s logical behavior from a Cloud AV, why let something run if it’s malware, honestly why even let it run in the FV sandbox if it’s known malware? If it’s known then it should not be allowed to execute in the first place unless the user decides to ignore it!

5. Any other information:
I’d like to clarify that it should NOT wait for the cloud to analyze the file dynamically, it should only wait for the static detections since otherwise it would be blocked for too long! Thus, for the majority of files it should only be blocked for the fraction of a second it takes to check the files classification.

The Comodo AV blocks files from launching if they are found to be malware, Cloud AV does not… Inconsistent behavior in my opinion.

I think this is a good wish. I made a small change to the first post. I added that also if the cloud AV times out while waiting for the classification of either malware, unknown, or safe, it should also default to allowing it to run. I assume that is also what you wanted, but I want to make sure.

If the first post seems correct let me know. I will then add a poll and move this to the Waiting Area.

Thanks.

Thanks, that addition makes sense and I meant for it to be in there but I think I worded it very poorly, your wording works very well! :slight_smile: Looks good now.

Thank you for submitting this Wish Request. I have now added a poll and moved this to the WAITING AREA.

Please be sure to vote for your own wish, and for any other wishes you also support. It is also worthwhile to vote against wishes you think would be a waste of resources, as implementing those may slow down the wishes you would really like to see added.

Thanks again.

Great idea but cloud checking takes just a fraction of second. I don’t really understand why file should be blocked until hash checking is done.

Ah maybe you mean CAMAS analysis on the NEVER seen files ? (ie if file has never been seen it’s sent to CIMA but response may take a while before coming to user PC, from 1 min to 15 depending on load. I think for that case your idea (for CFW) would be usefull.

No opposite, CAMAS would take too long in my opinion.

Sure, it only takes a fraction of a second for the hash lookup, but during that checkup the malware is allowed to run aswell as after the alert is on-screen, and as you say it only takes a fraction of a second so if the executables are blocked during that time then most users won’t notice since the programs will run if the file comes back as unknown/safe BUT if it comes back as detected then it should continue to block the file unless the user chooses ignore in the alert, just like the normal Comodo AV does, I want the same behavior in Cloud AV.

I got it now. Voted yes.

I would like to thank everyone who has voted on this particular enhancement. As there have been 20 or more votes, and more than 75% of those votes were positive, I have added this to the tracker for consideration by the devs. However, do note that even though this wish will be considered by the devs, it does not necessarily mean that it will be implemented. I will update this topic when I have any additional information.

Thank you.

Unrecognized items already become ‘isolated’, i.e., sandboxed until they become trusted.

Allowing a sandboxed item to phone home may not be such a great idea; akin to opening a spam eMail and the images it contains alert the sender that the eAddy is valid.

If a sandboxed item is allowed to phone home, malware devs would be aware that the IP address is valid.

I see this issue akin to malicious ICMP.

EDIT POST not possible? Hmmmm.

Need to revise and amend previous post: unrecognized sandboxed items should not be permitted IP traffic of any protocol, should be automatically logged and should be indicative: blocked; unrecognized & sandboxed.

An alert to that affect would be nice too. The description should be informative that this is a proactive measure due to the unreecognized nature of the file.

How is the above relevant to my wish?

I definitely think this is a good option and I would like to see some tests done with this option to see how well it works in practice, be good to see how well it protects against malware and whether it could help to protect those that are not knowledgeable with computers or security better then the current way of working :slight_smile:

Okay, I need to clarify some parts of this Wish. Are you saying that with the cloud AV enabled the executable gets alerted but not quarantined (by quarantined I mean that the current process is killed and blocked from future execution) even after detection?

Or are you saying this blocking does not occur before detection (which may be caused by a delay because this is the cloud AV).

How exactly does this work?

Thanks.

With the current implementation, when you run a malware it is allowed to run first and then the Cloud analyzes the file and THEN alerts that it’s a malware, at this point the malware is still allowed to run and the Cloud AV does not in any way block it from doing anything even though it has just alerted about the file, i.e it does NOT kill the process (unless the user clicks “Clean” in the alert) and lets say the user clicks “Ignore Once” and then manually kills the malware and then runs it again, then it’s still allowed to run and is not blocked from running and the Cloud AV will again alert about the file, now don’t answer the alert at all and instead let it stay on the desktop, now kill the malware and run it again, it will be allowed to run even though the alert on the screen is still claiming it’s malware.

And yes I know there’s a delay in Cloud AV, but during the look up delay the executable should be temporarily blocked in my opinion, NO executable should be allowed to run BEFORE the Cloud has EXPLICITLY come back with the results SAFE OR UNKNOWN, ONLY THEN should the file be allowed to run (unless no connection to the cloud can be made and then at time out the executable should be allowed to run) And if the Cloud comes back with MALWARE then the executable should still be blocked from running and the alert should show and ONLY if the user chooses “IGNORE” should the executable classified as malware be allowed to run.

I hope the above is clear enough =S

Thank you for the very well-worded explanation. I have added that explanation to the tracker and will let you know if there are any other questions.

Thanks.