With automatic sandboxing the test fails. Also with D+ it can be stopped
With sanbox disabled and D+ in Safe Mode there are two distinct warnings in red for very suspicious behaviour:
Changing an executable (first image)
Changing a dll file (second image)
Also suspicious is that Opera is no longer recognised (third image).
[attachment deleted by admin]
I’m getting different results to you Eric. The only alert I can generate, is the browser connection request, but only if the browser doesn’t have a firewall rule. It also makes no difference if the sandbox is on or off.
One note, the test didn’t work at first, but that’s because I was using a zipped build of fx, so it wasn’t actually installed in the usual location.
Of course, the crux of the issue is, how easy is it for an application that shouldn’t be trusted, to find it’s way into the TFL. Without that, this will fail.
I’ll try some other things and see where it goes…
[attachment deleted by admin]
Paranoid mode prompts accordingly
[attachment deleted by admin]
I tested again on Win 7 x86 in VM Ware with sandbox disabled and D+ in Safe Mode. I allowed every alert. When done I restarted CHALeaktest. It was not a safe application.
Did you place CHALeaktest in the TFL?
Of course, because paranoid mode is ignored TFL! But who usually works with Paranoid mode turned on?? I think nobody does.
I tested with Defense+ mode - Safe Mode and Firewall mode - Custom Policy. I think this the most widespread settings or even higher(safer) than most widespread settings.
As for SandBox I turned it off. It is always turned off in my Comodo settings.
Yes he must manually(but temporarily of course ) add CHALeaktest.exe into TFL.
If you say about enabling Sandbox Security Level in Defense+ settings then yes - I have no effect of the leak only in this case. Maybe this is a decision. But I didn’t learn Sandbox mechanism yet. Can it be turned on always during my usual working? And in this case can be any problems in the working of other applications?
And it’s also worth saying that I have tested with Sandbox CHALeaktest.exe and CHALeaktest_na.exe. I add them into Always Sandbox with Restriction Level Restricted. Comodo has FAILED the test.
Only in paranoid mode. Do you really use it in your usual working? 
You didn’t add CHALeaktest.exe and CHALeaktest_na.exe into TFL. All your screenshots except CHALeaktest 5.png tell about this.
As for screenshot CHALeaktest 5.png, I think you don’t allow Opera connect to the Internet, there is no rule for outgoing TCP connections on port 80 for Opera. How do you work with it?
I made new uploads. There were some errors in the first versions.
CHALeaktest.7z
CHALeaktest.zip
And also update the instructions for testing:
1) Close all application windows. Especially you should be convinced that Opera, Firefox, Chrome, Total Commander are closed. 2) Set for CHALeaktest.exe predefined policy "Blocked Application" in Firewall Rules. 3) Be sure that CHALeaktest.exe is not added into Defense+ Rules(no entry). 4) Set Firewall Mode to [i]Custom Policy[/i]. 5) Set Defense+ Mode to [i]Safe Mode[/i]. 6) Disable[i] Defense+ Security Level[/i] in [i]Sandbox Settings[/i]. [b]7) Add CHALeaktest.exe into Trusted Files list[/b](temporarily of course).
That 's true. But who really don’t have this rule for browsers? What is the browser used for then? I don’t understand.
Screenshot F2.jpg proves that Firefox have an allowed TCP connection to port 80. This is the standard rule for all browsers. I don’t understand why EricJH got his CHALeaktest 5.png. The only explanation to it is that there is no rule for outgoing TCP connections on port 80 for Opera.
Of course this the first step for malware. But as I already said it’s not very difficult, it is easy if somebody really want to do this. But I don’t want to pay money for certificate :). I only want to pay attention of Comodo developers to this hole and potentially possible leaks. And if developers of Comodo will close this hole and will use hash checking, then even if a malware will have digital signature it can’t connect to the Internet.
As I said elsewhere, this topic has been around for a long time. Here’s a thread from 2007, where the lead developer of CIS explains all.
I disagree. Automatic placement of the files into TFL is the potential hole.
I disagree. A malware can simply bypass CFP because almost all users don’t care about entries in the TVL. And TVL now is too big and that’s why it is not so difficult to get certificate with fields “CN” and “O”, which will coincide with one of TVL entries. Being an application from trusted vendor malware automatically will place into TFL.
If Sandbox Security Level is disabled and if is used default configuration “Firewall Security” or “Internet Security” then if malware has a digital signature with CN and O fields which coincided with entries in the TVL, it will bypass Defense+ easily, because it will be placed into the TFL automatically and Comodo will ignore Defense+ rules for this application. So malware can replace any file, which have an allowed firewall rule for OUT connections and will be able to send data from your computer silently, at least, until then while checking of the hash will be absent in Firewal Rules.
Guy’s that answer is 5 years old talking about the product CFP 3.x
Loads of changes have been made in between, and when AV/Sandbox/TVL was introduced this all has changed if you ask me, from then HIPS isn’t pure HIPS anymore (unless your run Para).
I agree that it’s not hard enough to bypass the TVL if you can code-sign your ‘app’ your in, on the Trusted list to much access.
So there are a few things that need improvement here (my version here):
On the other hand how many % of the current malware is code-signed or uses a ‘stolen’ cert? But as with everything it’s a matter of time and $$
It’s not just the TVL though Ronny. If the TVL is removed by deleting all files from:
C:\Program Files\COMODO\COMODO Internet Security\database
after a short period of time ‘trusted.db’ and ‘submit.n’ are recreated and the Trusted Files List gradually repopulates. I assume this process must be something inherent within the program, because it still happens even when everything but the firewall is disabled and all CIS processes are prevented from connecting to the Internet.
I think, enabling of Defense+ Security Level in Sandbox Settings doesn’t save! I have tested Comodo Leaktests (CLT) with this option enabled and manually add clt.exe into TFL.
I have at least 12 tests that were failed!
So, we have a key problem - automatic adding of the files into TFL. I think this topic is really important.
[attachment deleted by admin]
That has something to do with signature verification process and performance AFAIK.
CLT is useless in the sandbox as it’s a HIPS tester and not a sandbox tester.
Have you run it on a clean system without any security software? seen how many there already fail by OS restrictions?
You can keep the TVL from repopulating by replacing vendor.h and vendor.n with fakes. Just make a blank text file with Notepad for each one and replace them. This will keep the TVL clear permanently.
trusted.db is for the Trusted Files List
vendor files are for the Trusted Vendors List
Indeed. However, whereas the Trusted Vendors List won’t repopulate if CIS is prevented from connecting to the Internet, the Trusted Files List Will. You can create a dummy trusted.db file but you’ll also have to change the permissions to prevent it updating.