Frequently *updated* applications cause difficulties for D+ [271]

Also this happen to list of trusted files with newer updated versions. The app has to be added again in list and the previous entry stays there too.
Trusted (unrecognized maybe too) list can have multiple entries of the same but updated file -this is a small bug in list handling procedure.

It’s not really a bug in the way the list is handled. It’s just that CIS sees the updated application as a completely new application because the File Hash is different. So both the old and updated versions show up on the list as both are valid, they just happen to have the same name. Assuming the old version has been over-written however, you can use the Purge feature and it should be removed from the list.

I think Comodo needs to figure out a more elegant solution in regards to updated applications.

Please see the fix in this FAQ here.

That’s not really a fix. It’s a counter-intuitive workaround.

Yes, classifying things as installer/updater keeps the sandbox from continually grabbing an updated application. However, classifying countless applications as installer/updater when they are neither an installer nor updater isn’t I think, the way to go… This needs to be addressed.

I would be very grateful if someone, perhaps HeffeD, would create an issue report in line with the bug forum guidelines and format here. You can copy and paste the format from this topic.

To understand the reasons why we ask you to follow these guidelines please see below.

Bugs/issues can be impossible or very time consuming to fix if developers don’t have enough information to reproduce them. Since CIS is free, development time is limited. So if you want your issue fixed, please use the format below to describe it.

To avoid clutter, issues not described in the format below your post will not be moved to the ‘moderator verified’ issues topic. This means that the developers may not look at it.

Best wishes and many thanks in anticipation


D+ and the sandbox don’t handle frequently updated files very well. Each update is deemed an unrecognized file and partially isolated.

  1. What you did: Self compile a Java application in the form of a .jar file. This is often done several times a day.

  2. What actually happened or you actually saw: Each new compilation is grabbed by the sandbox and ran partially limited, added to the unrecognized files list, and sent to Comodo. If I answer not to isolate the file again, or add the new file to my trusted files list, I end up with multiple instances of the exact same file name in my trust applications list.

  3. What you expected to happen or see: As the file has been added to my trusted files list as well as the AV exclusion list, I would expect CIS to leave this file alone.

  4. How you tried to fix it & what happened: The only way I’ve been able to get CIS to leave each newly compiled file alone is to assign it the predefined installer/updater security profile. This is counter-intuitive as this application is neither an installer, nor an updater. It has merely been updated. There needs to be added functionality to deal with frequently updated files/applications.

  5. Details (exact version) of any software involved with download link: It’s somewhat irrelevant to add the software I use to compile this application as it is not a fault of the compiling, it’s a fault of Comodo jumping on each new compilation.

Your set-up

  1. CIS 5.0.162636.1135. AV database is irrelevant as it happens with every update since installing this version of CIS. Internet Security configuration.

  2. Clean install. No importing.

  3. Sandbox enabled, firewall and D+ in safe mode. AV set to stateful.

  4. XP Pro SP3, 32 bit, Administrator.

  5. Malwarebytes, SUPER Anti-Spyware, Emisoft Anti-Malware, Avira Free and Avast used for on demand scans only. No real-time functionality active.

Thanks HeffeD

That’s a very clear bug report.

Forwarding now.

To devs: this is an inevitable side effect of the generally highly desirable policy of identifying files by hashes, I guess.

But things could be made much easier for users if the asb alert has an option which allowed you to say ‘this is a frequently updated file’ when you indicate you want to trust the file. The trusted file list could then have a column to indicate which files are being treated as trusted installers/updaters. The latter is needed anyway, since I note that CIS remembers that some trusted files need UA - I guess this means that CIS treats them as installer/updaters?

Best wishes


Yes, that is much what I said in my wishlist post.

Sandbox should accommodate constantly changing applications/files

In the last paragraph:
I think another option is necessary on the initial sandbox dialog to accommodate files that are expected to frequently change. If that is deemed too much of a security risk for the unwashed masses to accidentally click, perhaps a new security policy can be instituted that has a much more appropriate name? I don’t know, something like Trusted/Changing or perhaps Path Based?

And by Path Based, I mean institute a path based exclusion in this instance instead of comparing the file hash.

Hmmm… Isn’t is a security hole?
Malware changes a file and let it there… same name and path… ???

Exclusions can always be risky, but they are sometimes the only alternative.

As it’s a custom application, I’m not very concerned about malware dropping a payload with the same name in the same directory…

So, avoid system folders for that (Program files, Windows, Documents & Settings, and so on).

In CIS 5.0.163652.1142 I am unable to trust a directory which makes C++ compilation BAT files a pain

The bug/issue

  1. Attempt to build a C++ project
  2. CIS sandboxes the C++ BAT build files
  3. I’d expect to be able to trust the intermediate directories so that any new BAT build files will automatically run but this is not possible so sandbox alerts are always displayed.
  4. Select not to sandbox again doesn’t work because C++ can use a different BAT file name each time
  5. VC++ 2002
  6. Any other information you think may help us:

Files appended

Your set-up

  1. CIS version, AV database version & configuration used: 5.0.163652.1142
  2. Whether you imported a configuration, if so from what version: Same settings as CIS 4.1
  3. Defense+ and Sandbox OR Firewall security level: Sandbox enabled
  4. OS version, service pack, no of bits, UAC setting, & account type: Win XP Pro SP3, 32bit
  5. Other security and utility software running: None
  6. Virtual machine used (Please do NOT use Virtual box): NO

CIS deliberately makes it difficult to trust whole directories. Malware could drop a file in a trusted directory.

You can work around as follows. Add the directory to the CSP with the policy updater/installer. Do this by using Add in D+ rules, selecting any file, saying OK, then editing the resulting path to be the directory path ending in *. OKing that.

I think the valid issue here is the problem with frequently updating files - I will maybe merge the topics. Don’t think Devs are likely to allow adding of directories (as distinct from all files currently in the directory) in trusted files.

Best wishes