Stop blocking my scripts!!!

I am just tired working and 1000 times per day seeing this COMODO false positive rubbish* behavior :

http://i92.fastpic.ru/big/2017/0702/34/b94ad0fb55c0e6d5cfe21ba50cd64a34.png

PS: of course I’ve configured CIS. In Settings->File Rating I’ve created my own file group and add the folder with my *.ps1 scripts into it. No success! Also I configured Auto-containment the same way (trusted group\folder added), and guess what? It continues to annoy me…)

Go to Advanced Protection tab of Comodo and go to Miscellaneous, and for the heuristics command line analysis turn off powershell.exe in the command-line analysis and embedded code detection.

Yousername, thank you! It seems to be working.

Can someone help me with this warning:

http://i95.fastpic.ru/thumb/2017/0702/85/9d598a34b9f0750f96d16cfc24a8f085.jpeg

Here I run Maven this is ordinary java build application. And nevertheless it says that everything fine, obviously some plugin didn’t finish its work correctly

We should collect this answers for future searchers as some sort of Comodo Settings FAQ for java developers

You have auto-sandboxing on and the app isn’t signed by an approved signer and originate from a Comodo Trusted Vendor. Comodo therefore sees it as unrecognized and the auto-sandbox rule to run virtualized “Unrecognized” file/application automatically kicks in.

Use the “Unblock Applications” element on the widget or open settings GUI to Tasks (left side mid-top)->General->“Unblock Applications”. Unblock your process.

Caveat to this is that “UA” creates 3 100% allow rules (incl all areas of protection->Firewall/HIPs/sandbox). It also changes the file rating for the app/file in the files list from “Unrecognized” to “Trusted”. Nonetheless, you may trust this process and leave all the allow rules, but you may also in the future want to delete/remove HIPs/Firewall allow rules after using “Unblock Applications” for some other file/app. Sadly, you will still have to manually change the file rating too to “Unrecognized” in the Files List for HIPs and Firewall to function fully. Also, the sandbox rule created by unblocking it is an ignore->Trusted rule >:-D. This will have to be edited to ignore->“Unrecognized”. o/c you shouldn’t have to do this manually, and there is an easy way around all of it for the devs. That’s something Comodo already knows. I posted about all of the above, and FutureTech said the devs were looking into the options. They aren’t complicated to fix as much as it may sound so. I have already provided them pics, so I hope they push this one fast honestly.

All this said, “Unblock Applications” is the only option for unblocking the sandboxing (containment) other than on the sandbox alert or manually adding a rule for the process to Allow it to run outside the container. Either of these is clumsy, though, because it requires a restart of the application. Also, if you miss the alert opportunity, you will have to use “Unblock Applications”, so I feel it’s a very good idea to know what it does. On the plus side, unblocking from the sandbox alert does only create a single sandbox rule (no HIPs or Firewall). Unfortunately, the file/app still automatically based on your unblock choice gets the “Trusted” rating, which it should not since you are only seeking to unblocking the sandbox element. With a “Trusted” rating I don’t even think heuristic-command line (Advanced Protection->Miscellaneous) will monitor the process. Definitely HIPs and Firewall do not. Again, I posted about this in another thread, and I think Comodo is presently working on something based on the discussion in the thread.

BTW, I don’t think you should turn off c-l monitoring for Powershell honestly (if you possibly can). It’s one of the most common applications used by malware/ransomeware. Chrome fires the same script alerts here on PCs here when I open the program b/c of a security extension, but I have learned to live with the issue, which I feel confident Comodo will deal with at some point. This is another one they know about from many post concerns. I actually have all the heuristic c-l protections (both columns) set to on with no problems at all. Maybe it won’t work that way for a dev, idk.

If you are confident in the sandbox as your single protection, be careful what you let out and keep in mind the “Trusted” rating issued by Comodo programs to user “Unblocked” applications. If you are still confident, heuristic c-l won’t be necessary since sandboxing will always/almost always happen before any command lines run. It’s nice to have it in the background though in case you make a mistake letting something out of the container.

Didn’t mean to write a book, but it is what it is I guess. I have had similar issues, and this is my experience with some of these same pitfalls of Comodo. It’s still a great concept and great protection. Just hope they see how much it would mean to do the simple refinements to the unblock sequence. :slight_smile:

BTW, if you would like to lobby for a fix to the “Unblock” issues, please read this thread (it’s pretty interesting):

https://forums.comodo.com/install-setup-configuration-help-cis/using-widget-to-unblock-t119889.0.html

Add 2 cents if you care to. Good luck with your issues…

I have only seen one possible workaround to exclude scripts from monitoring https://malwaretips.com/threads/how-do-you-secure-powershell.70981/page-3):
Andy Ful:
“The ‘Embeded Code Detection’ catches fileless scripts, converts them into files in the: C:\ProgramData\Comodo\Cis\tempscrpt
folder, and finally throws into the sandbox. This fucntion + heuristics has to be quite efficient in script blocking. People on Comodo forum complain, that their scripts (Visual Studio project assemblies) are autosandboxed, when “Do Heurristic Command Line Analysis” is activated. If one wants to run embedded scripts, he can activate the HIPS, and give the script hosting executable, the Installer/Updater policy.”

But I think Comodo File Rating by default trust all files by trusted installers. The File Rating actually works with the HIPS in that the child files which are treated as “Installer/Updater” in the HIPS rules are also trusted, by default Windows updater and Comodo updater apps are included. Otherwise, if a parent process is recognized but the child process of the parent is unrecognized, then the unrecognized file is dealt with accordingly. Source: File Rating Settings, Virus Protection, Internet Protection | CIS Help | COMODO. Actually, I posted a comment regarding this in NotPetya vs CF Video by cruelsister1, a user asked if a trusted updater which downloads malware from a hacked server would lead to a bypass.

So I’m not sure if the above solution would keep the protection in place properly, because the child files of the parent application are trusted if you apply the “Installer/Updater” ruleset, that can be problematic because interpreters like PS and wscript are often used to download malware payloads, and the malware payloads are the child process. If user were to untick the trust files by trusted installers, then I don’t see a point since it would be the same as leaving it on and not applying the Installer/Updater ruleset.

@AtlBo About the part where you say commandline analysis are not applied to trusted files, I think Commandline monitoring works like this:

It does not affect overall command-line analysis for interpreters, for example powershell is trusted BUT it is in the “Perform Heuristics Command-Line analysis for certain applications.”
If you move a script to trusted files, then Comodo treats it as a trusted file and lets it run accordingly. When Comodo catches scripts, the script is recognized by Comodo as an unknown file and runs with the same policies as any other regular unknown file.

[at]AtlBo About the part where you say commandline analysis are not applied to trusted files, I think Commandline monitoring works like this:

It does not affect overall command-line analysis for interpreters, for example powershell is trusted BUT it is in the “Perform Heuristics Command-Line analysis for certain applications.”
If you move a script to trusted files, then Comodo treats it as a trusted file and lets it run accordingly. When Comodo catches scripts, the script is recognized by Comodo as an unknown file and runs with the same policies as any other regular unknown file.

OK, so what if I install say Google Chrome, when it is from a “Trusted Vendor”. I’d have to go back in my mind to this scenario, because I use a shortened TVL. I don’t get this opportunity all that often, and I haven’t focused on it particularly. In the scenario where Google is a Trusted Vendor, what about its command lines later? I haven’t gotten any heuristic c-l alerts for that. Don’t see any in NVT ERP, so maybe that’s a bad example. However, I don’t have any (this is a recurring one due to random name of temp file) from any apps but one (and then one time alerts (allow and remember) from normal scripts that I have placed and run). Actually, I must have blanket allowed it and Google Updater, which I am almost positive uses scripts in NVT ERP. Anyway, I am not seeing script host h c-l alerts, much at all, so that’s why I thought “Trusted” must be attached more or less to the heuristic c-line analysis. Actually, I think I have only rarely ever used the “Treat as Installer”. I’ve just been paying more attention to it lately. At any rate, in contrast I have a web extension that causes an alert every time I open Chrome (and drops a file in tempscrpt because it’s named randomly), even though the maker of Chrome and the maker of the process that connects to the extension (360 web shield from Qihoo) are both in the TVL.

That aside, would you agree that the unblock concept (from sandbox or via “Unblock Applications”) should be modified to leave files as “Unrecognized”? Then the simple split unblock dialog works which can easily create allow->Unrecognized rules. This seems like the place to start for Comodo with trust. If the unblock is worked out logically for users, then changes over script monitoring can just as easily as they could now revolve around that. As it is, it seems like soup to me. I love the product, but who can sort through all this?

I have a feeling that beyond the image I attached to split unblocks, which seems simple to implement and then keeping “Unrecognized” rating for user unblocked apps (either way), there is clarity in these script refinements. I admit it would drive me crazy to be constantly getting the h c-l alerts if I were a dev. I’m sure that’s high on Comodo’s list to fix.

Thx for the breakdown of HIPs/c-l monitoring. I view it more in the light of unblocks for now (something else I hope gets looked into), since I only get the one recurring script.

For Google Chrome, if I have cmd.exe embedded code detection enabled, I do occasionally see command-lines getting contained, though I can’t reproduce it reliably. Try enabling the embedded code detection for cmd.exe if you haven’t already and see if you can get any alerts when using chrome. A lot of legit apps use cmd, if chrome were to use some script in cmd then I think h c-l would come into play. Haven’t used NVT so can’t comment on it.

Anyways, here is my opinion on the unblock concept. Now don’t quote me on this, but I think that if you create allow rules (ie. in HIPS) I assume that the HIPS still monitors the application if you left it at unrecognized. It simply automatically allows the activity. Whereas for trusted files the monitoring is actually pretty much excluded as indicated by the Comodo Help page, rather than the file still being monitored, just that it is silently allowed each time due to the rule. So for normal cases, changing file rating to trusted is adequate and is more efficient if the user wants to pretty much unblock the app completely. For special cases where Comodo still interferes even if it is trusted, then the unblock rules come into play. And of course if the user wants to only remove some protections then the unblock rules are also used without changing the file rating.

For Google Chrome, if I have cmd.exe embedded code detection enabled, I do occasionally see command-lines getting contained, though I can't reproduce it reliably. Try enabling the embedded code detection for cmd.exe if you haven't already and see if you can get any alerts when using chrome. A lot of legit apps use cmd, if chrome were to use some script in cmd then I think h c-l would come into play. Haven't used NVT so can't comment on it.

NVT ERP catches everything with the Vulnerables I have added. Google is trusted in NVT ERP. In Comodo, I do have cmd.exe and all the rest too enabled in h c-l selections. Also, I have all the embedded detections turned on. I suspect your security app browser extension could be causing you to see the alerts when opening Chrome->same issue I get. Qihoo has anti-keylogging support from the main a-v program for their web extension. This connection is what is flagged as embedded for me when opening Chrome. Comodo turned off some of the h c-l protections with one update, and these did stop for me. However, I wanted them all and determined it was worth the price of an alert from Chrome.

BTW, NVT ERP’s Vulnerables list does the same thing as h c-l, except that it alerts all c-l activity from vulnerables. The command line can then be individually whitelisted. NVT supports user wildcard changes to whitelist entries, so randomly named scripts that are the same script over and over can be dealt with that way. Only get the script once because of the wildcard entry that covers all of them. Obviously, this kind of hands on approach won’t be for Comodo, but I do feel there is an answer that doesn’t require user interaction with whitelisted command line rules. I’m sure we will see this soon enough. Something like OK, from this “Trusted” app->captured c-l text is identical to existing tempscrpt file->don’t alert. So maybe responsible app will have to be in the tempscrpt as a script dev note or something, who knows.

On the additional layer for unblock in the picture in the linked thread, I ran some scenarios on a simple “Unrecognized” file/app again tonight. This time I chronicled everything that happens. These cover the kinds of rules and actions from Comodo when one of the unblock mechanisms is invoked. Here they are:

Scenario 1 No Unblock
Run app XYZ.exe “Unrecognized”->Auto-containment alert->No unblock by user choice->no rules by Comodo->File rating stays “Unrecognized”->File is auto-recorded by Comodo in “Unblock Applications”->User chooses to unblock via “Unblock Applications”->After"Unblock Applications" unblock->File rating to “Trusted”->Firewall rule for Application XYZ.exe “Allow All Incoming and Outgoing Requests”/HIPs rule for Application XYZ.exe “Ask” to execute and “Allow” all other HIPs behaviors/Containment rule Application XYZ.exe Ignore if Application XYZ.exe is “Trusted”

Scenario 2 Unblock via Containment alert
Run app XYZ.exe “Unrecognized”->Auto-containment alert->User select “Unblock this application” on the Containment alert->File rating to “Trusted”->Comodo auto-creates Containment rule for for Application XYZ.exe Ignore if XYZ.exe is “Any” rating->No other rules->File is auto-recorded by Comodo in “Unblock Applications”->User chooses to unblock via “Unblock Applications”->After “Unblock Applications” unblock->File rating remains “Trusted”->Firewall rule for Application XYZ.exe “Allow All Incoming and Outgoing Requests”/HIPs rule for Application XYZ.exe “Ask” to execute and "Allow’ all other HIPs behaviors/Containment rule Application XYZ.exe Ignore if XYZ.exe is “Trusted” (same as after the “Unblock this application” allow)

Scenario 3 Unblock via “Unblock Applications” element
Run app XYZ.exe “Unrecognized”->Run app XYZ.exe “Unrecognized”->Auto-containment alert->No unblock by user choice->No rules from Comodo->File rating stays “Unrecognized”->File is auto-recorded by Comodo in “Unblock Applications”->User chooses to unblock via “Unblock Applications”->After"Unblock Applications" unblock->File rating to “Trusted”->Firewall rule for Application XYZ.exe “Allow All Incoming and Outgoing Requests”/HIPs rule for Application XYZ.exe “Ask” to execute and "Allow’ all other HIPs behaviors/Containment rule Application XYZ.exe Ignore if XYZ.exe is “Trusted” (same as after the “Unblock this application” allow)

Red indicates dangerous unblock of “Unrecognized”. It’s easy to see how the danger creeps into the decision making portion of these scenarios, where the red is in the bold area. User is often not even aware of what is happening when they unblock. With scenario 2 or 3, the unblocks, no matter what all three aspects of protection are turned off, irregardless of what the user would like. If user would still like HIPs or Firewall or whatever, well they are all off sorry :-[.

Focusing on these bold areas, it’s possible to see that if the rating were left at “Unrecognized” after using one of the two unblock methods, rules could be auto-created by Comodo that would turn off protection for any element the user wants off…even with file/app still at “Unrecognized”. This is possible. And this means a dialog for individual protection unblock could be created/added in “Unblock Applications”. Then the choice to “Unblock this application” located too conveniently for me on each Containment alert, could be replaced with instructions to use “Unblock Applications” on the widget or in the GUI->Tasks->General tab to unblock, where user could choose what to unblock. Even two or all three protections could be selected at the same time to unblock. This would be a huge improvement in user safety imo if the user had to use the “Unblock Applications” element to remove an “Unrecognized” from containment. The danger would be removed from the decision making process, because the process would be different, eliminating the danger. Specifically, this is achieved by removing auto-“Trust” from the unblock dialogs in Comodo. Also, other protections could be left in place. No trust no danger.

Anyway, sorry, I know this isn’t OPs main issue, which I really hope Comodo resolves quickly for the sake of devs out there. I really think with these two fixes the program will be malware invincible and also user mistake invincible too.

Just a little thing to point out → on Windows 10 there is no option to unblock the app through the containment alert. Clicking on the containment alert shows the log. So for Windows 10 if the user clicks on the notification it should take the user to the unblock apps area, or maybe they can bypass Win 10 notification system somehow.

That sounds normal enough or just explain how to unblock on the alert-> use “Unblock Applications”. UA is right there on the widget anyway, and the extra seconds could mean greater safety, so I would go this way. The main thing for me is make it possible to unblock a single rule or two rules or all three. Keep the file rating at “Unrecognized” and then for the unblock mechanism auto-create rules that will function as chosen/desired with the “Unrecognized” rating. For “Unrecognized” I believe no rule is required for HIPs and Firewall to alert, because of global rules. User can choose when the rule first fires an alert. If the mechanism leaves the file “Unrecognized”, then there would be a rule required to turn an element off, so that the element would never create an alert.

I think you may not see the “Unblock this application” on the alert as a result of a settings choice. Could it be “Detect programs which require elevated privileges” or “Do not show privilege elevation alerts”? I don’t know, and you may know that this is the case on W10. If so, I was not aware of this fact. I am on W7 Pro 64 on a few PCs here using Comodo, including this one running Comodo Firewall.