When File Rating says "safe/untrusted"?

CIS: 6.0.264710.2708

I’ve done some research and before I report a possible bug I’d like to make sure about how Behaviour Blocker and File Rating works. Help pages are not enough informative or they describe only default settings.

Used settings:

  • HIPS: disabled (the only relevant feature is “Blocked Files”, but we don’t use it now)
  • BB: enabled, mode: does not matter
  • FR Cloud Lookup: disabled
  • FR Trusted Vendors: disabled

I’d like to know:

  1. What conditions are required to consider an application as untrusted? (sandbox alert)
  2. What conditions are required to consider an application as safe?

Please be specific about signed files and expired signatures.

Here is part of my research results (the // part is: settings above / FRTV+ / FRTV+ & FRCL+):

CCleaner 3.26.1888 - signed, valid = not sandboxed

Total Commander 8.01 - signed, expired = not sandboxed ← why? / not sandboxed / not sandboxed

7-zip 9.20 - not signed = not sandboxed ← why?

PuTTY Tray p0.62-r013 - signed, valid = sandboxed ← why? / not sandboxed & added

VisualHash 1.2 - not signed = sandboxed / sandboxed / not sandboxed & added
GPG4USB 0.3.2-1 - not signed = sandboxed / sandboxed / sandboxed

Read Unknown Files - The Auto - Sandboxing And Scanning Processes in the online Help. That may answer your questions.

Thank you for a reply. I’ve read all of the standard help topics about BB & FR, however they all treat when the default settings are enabled (i.e. Trusted Vendors and Cloud Lookup). The other problem is that the terms used for the same function’s description are different on some of those pages. Unfortunately none of them precisely explain how raw feature works (and it looks like that it differs from what we had in 5.x) and why unsigned (uncertified) files and files with expired certificates are passed as safe, but some signed files are sandboxed on the contrary. That is why I suspect an bug behaviour in that function. However I cannot report it without solid confirmation.

CIS will only accept a file as safe when it is both signed and on the Trusted Vendor List. Can you check whether the signed files are actually on the TVL?

Unsigned individual executables will be trusted when they are Comodo’s white list. It may happen sometimes that an individual executable gets whitelisted and its vendor is also on the TVL. In that case an expired certificate I assume will be discarded.

In case you have an executable that is not whitelisted as an individual executable and has an expired certificate could please point us to it. We may be looking at a bug.

Please read my first post:

TVL is disabled, CL is disabled as well.

What is “Comodo’s white list”? Is this something different than “Trusted Files” and “Trusted Vendors”? What options are connected with?

OK, I will repeat myself. :wink: Few examples from above:

  • Total Commander, version 8.01 32 bit

file is signed, but certificate is expired, yet file is not sandboxed (see attached fr-sig-tc.jpg)
yes, this vendor is on TVL, but trusting to TV is disabled

  • PuTTY Tray, version p0.62-t013

file is signed, certificate is valid, yet file is sandboxed (see attached fr-sig-putty.jpg)
this vendor is also on TVL, but trusting to TV is disabled

  • 7-zip, version 9.20

file is not signed, yet file is not sandboxed (see attached fr-sig-7zip.jpg)

[attachment deleted by admin]

There may be a local whitelist of trusted hashes. Can anyone confirm if there is this feature, or if it’s been entirely moved to the cloud?

There still is a local white list. That question came up in another topic and testing showed there still was a local white list.

Indeed, there is vendor.h file (hidden hashes) and vendor.n (TVL), but then - why signed PuTTY is found untrusted? And this is not the only one file signed and sandboxed. The others I’ve found are: CDBurnerXP 4.5.0.3717, Autoruns 11.4, Foxit Reader 5.4.4.1128. All of them are signed, but sandboxed. Most likely if I whould check all my apps there will be more of them.

Edit: OK, I get it, because being signed is not sufficient when hash is not added and TVL disabled. IMHO hash list should be public (as is TVL). Of course using real/exe names instead of hash string. :wink:

CIS has a white list of individual executables that are deemed safe. We have a topic where these can be submitted (this helps Comodo to prioritise the assessment of the many files that come in on a daily basis): Submit Applications Here To Be Whitelisted - 2013. This list exists both in the cloud and as a local database. The local database is hard coded and cannot be viewed.

In short files will get added to the Trusted Files list because:

  • Vendor is on the TVL
  • It is on the local hard coded list of safe files
  • It is deemed safe by cloud look up
  • Is installed by Trusted Installer
OK, I will repeat myself. ;-) Few examples from above:
  • Total Commander, version 8.01 32 bit

file is signed, but certificate is expired, yet file is not sandboxed (see attached fr-sig-tc.jpg)
yes, this vendor is on TVL, but trusting to TV is disabled


I did some testing with the Total Commander executable and it gets added to safe files because it is on the local white list.

- PuTTY Tray, version p0.62-t013

file is signed, certificate is valid, yet file is sandboxed (see attached fr-sig-putty.jpg)
this vendor is also on TVL, but trusting to TV is disabled

That would be a case of the executable not being white listed by the local hard coded white list. When I enable the cloud look up it will be deemed safe by the cloud.

- 7-zip, version 9.20

file is not signed, yet file is not sandboxed (see attached fr-sig-7zip.jpg)

I tested it and it is on hard coded database

I think you are starting to understand how CIS works.

TVL is already public in the sense that it can be viewed in CIS but the list of program names and hash codes are not public. They are semi public as it will only show for the programs users have installed.

Thank you for an explanation. However vendor.h seems not to be this list though. After moving it to other directory apps are still passed by. Don’t get me like a paranoid, but I prefer to trust by self or at least see what Comodo consider as safe. That was one of the reasons I’ve disabled sandboxing in 5.x. Also internal hash list is always enabled, so we cannot add such applications to unrecognised files to test it.

There is one more thing which is disturbing. For example good old system notepad.exe (or regedit.exe). This file is not signed, it is not in local hash list so it gets sandboxed, but with enabled TVL (Cloud Lookup is disabled) it is no longer sandboxed. Why? Keep in mind that this file has no digital signature. So what vendor string was used when comparing? From VERSIONINFO->CompanyName structure? That’s totally unsafe.

BTW:

Files trusted by local hash list are not added to Trusted Files on contrary to those matching TVL. Total Commander was never added to TF by CIS itself, only by KillSwitch which seems to arbitrary add everything on start.

[Post removed]
Need to think about this further

Mouse

I believe it checks the hash, not just what the properties read.

Notepad is signed, I think. It’s catalogue signed - that it it’s signature is held in the Windows signature catalogue. For some strange reason such signatures don’t show on the signature tab.

The most reliable signature checker I have found is Sysinternals (see M$ site) sigcheck.exe. Do sigcheck -i -e and you’ll get the right gen.

Best wishes

Mouse

You are right sigcheck retrieves signatures for those files.

May be the TVL gets loaded in RAM when CIS is running. That would be another explanation.

Don't get me like a paranoid, but I prefer to trust by self or at least see what Comodo consider as safe. That was one of the reasons I've disabled sandboxing in 5.x. Also internal hash list is always enabled, so we cannot add such applications to unrecognised files to test it.
Setting D+ to Paranoid and Firewall to Custom Policy mode will make that happenIf you want to switch off the automatic trusting mechanism you can do that under [url=http://help.comodo.com/topic-72-1-451-4778-File-Rating-Settings.html]File Rating Settings[/url]
There is one more thing which is disturbing. For example good old system notepad.exe (or regedit.exe). This file is not signed, it is not in local hash list so it gets sandboxed, but with enabled TVL (Cloud Lookup is disabled) it is no longer sandboxed. Why? Keep in mind that this file has no digital signature. So what vendor string was used when comparing? From VERSIONINFO->CompanyName structure? That's totally unsafe.
Explained by mouse1.
BTW: Files trusted by local hash list are not added to Trusted Files on contrary to those matching TVL. Total Commander was never added to TF by CIS itself, only by KillSwitch which seems to arbitrary add everything on start.
It gets added here by CIS (I tested on Win 7 and Win 8 ). What makes you think it is Killswitch? When it does not get added by CIS then something is up with your set up.

Nope. TVL (in settings) gets cleared when moving vendor.n file. The hashes must be hard-coded in some other place. Anyway I restarted system after moving those files to be sure.

I already do this for everyday use. :slight_smile: This config is for testing purposes only.

Well, no it is not. Total Commander, 7-zip and all other files recognized by local hash list are never auto-added to Trusted Files. Even with TVL and CL enabled. Only KillSwitch adds them.

But KillSwitch… what? I don’t follow this. KillSwitch analyses all running processes when started, right? And this is the moment when it populates CIS Trusted Files list. CIS was reinstalled three times to test this and other features. No other Internet Security packages are in use.

[edited]

I think the confusion here is the location of the ‘local white list’, and what is done with it.

If the white list still exists and work as in CIS 5.x, it’s located somewhere in CIS. I suppose it could be duplicated in Killswitch, but there would be potential integrity problems with such a setup.

It could I suppose be in the CIS executables themselves. That would make for fastest access. In which case it would be in Cmdagent.exe or CIS.exe.

The hypothesis is that both CIS and Killswitch use it, so if in a CIS executables, CIS would have to have an interface by which it is accessed. CIS presumably uses it for speed of access reasons? Otherwiose why have it as well as the TVL database (long so slowish - but not too slow, think it’s a beta tree).

How can you validate that the whitelist is involved?

If it’s not encrypted, and process explorer and killswitch can access CIS strings so it’s maybe not, in principle you could prove this with a disk sector editor and an SHA. You’d search for the SHA as a byte string.

You could also look for the interface using reflection or maybe searching CIS strings.

A way of working out whether something’s likely to be on a useful hash list would be to consider what the citeria would be. I’d say the executable would be more likely to be on the list if it were:

  • response or machine function critical
  • frequently encountered
  • infrequently updated

Apply this to your executables and it might tell you if you are likely to have a bug or not.

Best wishes

Mouse

Just thought of a simpler way.

Use a disk sector editor to change a byte in the executables and save to same file. See if Killswitch Trusts.

Then reboot to get round caching. See if Killswitch trusts.

Then create a copy of the amended file - with changed name same directory. Reboot and see if Kilswitch trusts.

Obviously keep an eye on all lists TFL TVL at all stages to see if anything is creeping in.

This should give a reasonable indication of what is going on.

Best wishes

Mouse

Yes, this is the most likely scenario. Because in other topic posted as a link here earlier - new application’s versions were not recognized, so internal hash list doesn’t seem to be updated, it’s static and gets updated with each new CIS release (most likely that’s why Cloud Lookup, the on-line list, is recommended).

I fully agree.

Coming to think of things. When manipulating the TVL I recall it must be done carefully because otherwise will reinstate it through one of the two web interfaces (Cloud lookup or program updater).

I already do this for everyday use. :) This config is for testing purposes only.

Well, no it is not. Total Commander, 7-zip and all other files recognized by local hash list are never auto-added to Trusted Files. Even with TVL and CL enabled. Only KillSwitch adds them.

I am using Proactive Security with D+ in safe mode which should yield the same results as when using Internet Security Configuration (which I assume you use). That still leads me to believe there is something with your test set.

But KillSwitch... what? I don't follow this. KillSwitch analyses all running processes when started, right? And this is the moment when it populates CIS Trusted Files list. CIS was reinstalled three times to test this and other features. No other Internet Security packages are in use.
I am starting to see what angle you are taking with KillSwitch. With KS now closer to CIS it may actually share some features; it will use the CIS av database when present. Assume that Killswitch is using a local white list as well as a cloud white list like CIS and that it can add files to the TF list of CIS.

If KS adds to the TF list then you should see different result for the situation where KS can check in the cloud or not (with network connection disabled). In the latter case Putty would not be added because that is not on the local hard coded white list and in the former case 7zip and Total Commander will be added because they get recognised by the cloud.