Comodo Firewall 12 Critical HIPs and Containment Failure

Comodo Internet Security - CIS Defense+ / Sandbox Help - CIS
1

Comodo Firewall 12 HIPs and Containment Failure

1: CIS version:
Comodo Firewall 12.0.0.6818
2: OS version:
Win 7 Pro x64
3: What you did:
Proactive configuration with HIPs in Safe Mode and containment set to Automatic. Tested the location protection of HIPs->“Protected Objects”->“Protected Files” by turning off containment and running a simple .bat file to attempt to delete files located at a remote drive location. Ideal outcome was a block of the simulated attack. Tested first with containment turned off and all other protections on. As expected, HIPs protected the remote location, which I had added to “Protected Files”. I then reenabled containment and turned off HIPs to observe the behavior. Comodo containment protected as expected, and the .bat was contained. I then reenabled HIPs and turned off containment one more time and ran the .bat. At this point I expected to see the HIPs alerts, but this was not the case.
4: What you actually saw:
The .bat file in the 3rd test configuration ran without an alert, even though HIPs was on. As a matter of fact, when the container was reenabled, the .bat still ran without an alert. I continued to probe this issue to understand the problem, and I unblocked the .bat from within “Unblock Applications” for all areas and then found and eliminated the rules in HIPs and Containment. Only the containment rule was there as expected, and it was deleted. The file was not present in the “Files List”. Again, I ran the test with only HIPs enabled, and this time the .bat ran without an alert of any kind. I again checked for the presence of the file in the settings and dialogs, but it was not present. At this point, I proceeded to re-enable “Auto-Containment”. Again, I ran the test, and, again, the “Unrecognized” test .bat ran without an alert, this time with both HIPs and “Auto-Containment” enabled. I continued to probe the issue, and I saved the Proactive configuration setting and uninstalled Comodo Firewall using Comodo Programs Manager. I then reinstalled Comodo Firewall again and restored the Proactive configuration settings that had been used previously and saved. At this point, I ran the test, and Comodo Firewall HIPs again blocked the file as expected. Obviously, malware isn’t going to alert me to reinstall Comodo Firewall, so this is clearly unacceptable. Somehow, Comodo Firewall in this scenario is remembering the file, while at the same time giving it a completely free reign on the system. Yet, the file does not even exist in the program dialog settings anywhere, including rules and or the “Files List”. Also, it is not present in the “Unblock Applications” area. This file is “Unrecognized” by default, yet it still can run any time and do anything.

How is this file getting a free pass? This is a systemic fail. I ran the test 3 separate times repeating all of the same steps above and with the identical results. Once a file has been contained, even if the file’s presence is removed in the “Unblock Applications” area and from the “Files List”, along with all rules for the file, the file is still given a free reign, even though according to Comodo it is unsigned and unknown and therefore obviously “Unrecognized”. PLEASE FIX THIS IMMEDIATELY.
5: What you expected to happen or see:
When I re-enabled the HIPs and disabled “Auto-Containment” for the second time, I expected the normal HIPs alerts, first for Explorer and then for the location attack. Neither came. And, when containment was re-enabled, neither HIPs, nor that protection issued an alert to the running “Unrecognized” .bat on the desktop. Again, the file wasn’t in the “Files List” or anywhere else in the Comodo Firewall dialog. How could it possibly have run?
6: If possible attach a screenshot illustrating the GUI problem
No screenshots. PLEASE JUST TEST THIS SCENARIO. An “Unrecognized” .bat file is able to run under the above scenario. How is this possible? This should be tested too when HIPs is turned off first to see if this simpler test produces the same result later, when HIPs is re-enabled and “Auto-Containment” disabled. I have not tested this scenario.

I have tried everything to resolve this. Once the file is allowed by Comodo, there is no way to resolve the problem. I ran the Comodo Repair, rebooted numerous times, uninstalled and reinstalled, checked the settings for secondary HIPs references for the file in Explorer.exe. Literally, there is nothing there to skew the test. This result bears witness with 5+ years of experience I have had with Comodo Firewall now as something familiar to me. I feel certain I have seen this before without realizing what was happening.

This appears to me to be a very serious issue. PLEASE test and let me know what is causing this result in Comodo Firewall. I feel certain it happens in CIS and in CCAV too. I haven’t tested these. PLEASE TEST THIS IMMEDIATELY. Thankyou.

2

"Could first attached picture from the “Unblock Applications” explain what’s causing the above bug?

“If you unblock an application in this list, it will be considered safe and not be blocked in the future”

Does this mean, that unblocked file is just dropped invisibly into the settings, inaccessible? User can’t change his mind about the file? If so, never would I have imagined that, even with no trace of the file in the settings dialog anywhere, Comodo would simply blanket allow forever a file just because someone wanted to see what it was or something and unblocked it from this area.

This is not AT ALL the way to handle this. I love the “Unblock Applications” area, but I have discussed before in posts the way trust is handled from this area and from the alerts. I am not joking…it’s like negotiating with terrorists…you just DON’T allow users to change trust. 100% build your app around the fact that users allow “Unrecognized” activity sometimes. Do it so that they will remember and respect your view. In the end, they will learn to trust your view.

To go further to explain, a user choice from the “Unblock Applications” area or from an alert should never affect the trust rating of a file in the “Files List”. It should only be possible to change trust for a user from within the “Files List” and then only after answering to an “Are you 100% sure?” lecture message, yes/no.

Well, it’s the same thing with this perma-allow that appears to be happening if that is what is happening with this bug. Basically, if Comodo is blanket (permanently) allowing a file once it’s been “unblocked”, even without it being present at least in the “Files List”, this is only leading to confusion, difficulty, and frustration. No doubt if a file is perma-allowed with an “unblock”, then that’s even more powerful than a “Trusted” rating that users can hand out via their choices on alerts and so on. In this case, the file exists as “Trusted”, yet doesn’t even exist in the “Files List”. It can’t be changed at ALL. This is not good, and it’s appears to me that there is no way to correct the problem for a user if all of this is true.

I recommended a while back a revamped “Unblocked Applications” area where the trust rating of a file is never changed with a choice, but users are given the option to individually allow activity based on protection. This is workable (see attached picture 2). Ok, this picture speaks for itself. Personally, I could tolerate allowing a change of trust if the user was willing to unblock all of the protections where the app has been blocked, that is if Comodo would auto-issue its default rating if the file triggered an alert later of a module that had not been used for a block before. If I were writing the program, I would simply go with a hard line on trust and revamp the settings of the program to match the hard line. It should only be possible to change trust in the “Files List”.

OK, well, I bring this up because the statement in the post at the top that is in the red box in pic 1, seems to indicated that Comodo’s protection is being broken by unblocks. If so, I am asking Comodo to fix this problem, or I will have to ditch the program. I am assuming I am right about what was happening here, but I took the time to confirm the findings, so I am confident enough to move on if I must.

OK, I don’t know what is going on, but whatever is happening, I stand by the trust rating. In the end, Comodo will see it my way about trust, or I guess the company just wasn’t as great an idea as I thought. Not that I am smart, I promise. It’s just that I cannot see a single way this app generates a nickle for the company if Comodo isn’t in charge of trust. This bug is about files being EVEN MORE than trusted. It’s bad news if I am right.

I come across angry, but the truth is I just have to move on if Comodo is going to continue to be this buggy and unreliable. The rest of the industry is speeding toward great things, but this marvelous protection scheme from Comodo is dying on the vine from a lack of refinement. Just asking please fix the bugginess and unreliability of the program. Other companies take it seriously when their product is constantly using 25 or 50% of the processor or when the program quits or just won’t protect like tonight. There are so many opportunities in the program. Almost makes me sick.

I hate to rant, because I love you guys for this concept. I hate to see it trampled though, and I don’t have time to wait around anymore. I am just one person, but this one person needs improvements and refinements. Please start here…

3

This is definitely an issue. Tested again today under different circumstances. Testing was done on an installation that was restored from an image 2 days ago. I had been testing at that time, but I ran the test in the present to see what would happen. With “Auto-Containment” set to disabled from “Manage Protections” on the main program dialog of Comodo Firewall, I checked all of the settings and reference areas where the file might appear in Comodo Firewall for its settings to be adjusted, including rules, the files list, and in the unblock applications area. I removed the file from the unblocked applications area, using the remove option to remove the reference only. I see no statement indicating that this should have changed the protection characteristics of Comodo (unblocking should add a rule(s) and add the file to the files list rather than somehow hard code trust forever as is apparently the case now). It may have been unblocked prior to the imaging that was done, not certain. Otherwise, however, the file was not present in settings, rules, or lists areas.

The results were, as stated, not the normal expected outcome from Comodo. Nope, this time Comodo HIPs alerted for the Explorer.exe startup of the .bat. This was allowed, since the test was to see if the Protected Objects->Protected Files element of HIPs would protect as expected. So then the file should have brought the “Protected files and folders” alert. Sadly, that never happened.

I probably unblocked the file using the “Unblock Applications” area and drop down to remove the single protection. If it was something else that caused only the Explorer.exe alert to happen, I am clueless what it could have been. At any rate, my choice to unblock, should not have introduced in any way some kind of hard coded perma-allow. Sure seems like what is happening to me.

One last time, PLEASE fix or explain this one of the two. ReHIPs is calling my name, and it’s the only other option, but I will sell out for the program if I have to change.

BTW, the sandboxing in Comodo is amazing and crying for further development. With all the applications and tools that have been designed by the company, please don’t tell me that Comodo can’t come up with a security program that can provide containment isolation for individual applications (user choice/Comodo recommendations), cleaning and maintenance options for sandboxed applications and for the rest of the system, special security checks for downloaded files (do not virtualize…“Downloads”/see OPSWAT extension), an uninstaller that will uninstall fully a program (Comodo Programs Manager is the best uninstaller on the planet), and secure backup that will guarantee that no application but Comodo can read or write to the backup location.

The only thing that might bestopping this that I can see is the need to update applications which are being contained. I’m not sure this is a problem, but Qihoo updates programs. SUMO exists only to update programs. Why not download updates and turn off containment and the internet if necessary and update the programs. Then start them up again. Maintenance is important.

C’mon Comodo, this is the future. You guys have to handle the trust issue and fix these protection fails in the short term. PLEASE DO THIS. All of the above is doable and a great endpoint too that doesn’t need even half of these extras…

4

By default the file list is filtered to only show executable file types such as .exe, .dll, .sys., etc.; .bat files are not considered executable files and won’t be listed in the file list unless you select all file types or non-executable files from the drop down selection. Now having said that when you choose unblock from all components, not only are rules and exclusions made for each component, but the file rating gets set to trusted in the file list. If you remove the file from the file list and re-launch the .bat file it will reset the rating to whatever rating Comodo has for that file, which in your case will be unrecognized.

Also it shouldn’t be a surprise that if you have other 3rd-party security software installed alongside CIS, you have a big chance of causing conflicts that affect the operation of CIS.