Why Comodo doesn’t use the hash in Firewall and Defense+ Rules? What is the reason??? If my program could connect to Internet it can do any malware. Do you understand?
No alerts from Comodo!!! User just click a shortcut of Opera, Firefox or other often used program , being afraid of nothing and any data can be send over Internet!!! This is a leak 100%. Because replacing a file is a small problem. PC Flank Leaktest nervously smokes aside! ;D
Do a search on the forums, there have been loads of complaints about this ‘leak’.
Don’t get me wrong I don’t like it either, I prefer the Kerio way having an alert ‘application X is replaced…’ allow yes/no.
Malware should not be able to mimic this behavior.
Let’s be defined that we speak about the most widespread case. The most users(most numerous) don’t delete any entries in Trusted Vendor List(TVL). For example, I (as skilled user) only now I am going to filter TVL after I learned how Defense+ work!
In TVL there are MANY different organizations(well-known and not so well-known) and private persons. It’s very easy to steal a private key of the private person or the small organization rather than at famous big organization such as Microsoft, Google, Adobe, Apple, Opera, Mozilla and so on.
Besides, it’s very easy to get a certificate where field CN(common name) or O(organization) will coincide with already existing in Comodo’s TVL.
Besides there can be a namesake in other country which can legally receive the signed certificate and his name will be in TVL. Comodo check only CN and O fields.
Besides, one of the private “developers”, whose name is in the TVL can want to play “pranks”! 
All written above lead to we have a malware that have a “legal” digital signature and the name of the organization or the private person is in the TVL.
After that usual user that runs this malware file can trust it, because it have a digital signature. Usual user can even let to run this program with administrative privileges if program asks them.
He can do it because more serious danger is when this program wants to connect to Internet. But he hopes for his Comodo firewall :), that it won’t allow any new program connect to the Internet without any alerts.
Now, such potential malware is already in TVL. But it hasn’t any allowed rule in the Firewall. What it can do?
After this it can replace without any alerts any file that not in system folders like “Windows” or “Program Files” and have an access to the Internet on 80 port. This can be Total Commander, for example. And after we(suspecting nothing) run Total Commander, the replaced file transfers all what it want to the Internet. No alerts from Comodo! This is really a leak! The smart malware can do it all in silent mode. I mean it transfer all what it needed and then returns control to the replaced program, unpacks the code of the replaced program directly in memory and user sees usual running of his program! The injection(replacement) can be done in many different variants. But we don’t get any alerts from Comodo because our program in TVL!
Certainly after that we loose the trust to replaced program for HIPS activity, but we really don’t need it!
Besides, if our malware would have administrative privileges(see above) it could replace any file in the “Program Files” folder. For example, opera.exe. firefox.exe or others. And we’ll get the same leak!
This all can happens because Comodo don’t check the hash of the file in Firewall Rules! But if Comodo will use the hash of the files in Firewall Rules and possibly Defense+ Rules(but this is already the next topic), nothing will happen because existing rules won’t operate - the hash is changed!
But you can ask that about legal update of really trustable program?
If there was an update of software and we installed new version of trusted program, that have at least one rule in Firewall(first of all) or Defense+, Comodo should notify us that the file was changed and should ask us: do we want to apply old rules for new trusted file if paths are identical. If file has no digital signature it’s not a trusted file and so question must not be asked and no any old rule should apply to this new changed file, and in this case the rules for this file must be temporarily disabled.
For example in Outpost Firewall we at least always get a popup alert that the trusted file was changed regardless who is changing trusted application or not.
Countermeasures.
Certainly we must filter our TVL and even more(because what usual user really think about this?): Comodo must have 2 TVLS, one(small) for trusted vendors(such as Microsoft, Google, Adobe, Apple, Opera, Mozilla) and one for others, not trusted vendors. Programs from vendors from the first list can be added to TFL automatically and programs from vendors from the second one must be added to TFL only with question.
Comodo must uses hash for files in Firewall Rules!
I remind that a key problem – automatic(without any popup alerts) placement of the program in TFL. Being in TFL, the program can do a heap of affairs. And in particular in the absence of check of hashes in Firewall Rules can silently sends the data through the network.
In addition to my previous post , I see that all files(with or without digital signature) that were in Protected files and folder list(PFFL) all are added automatically to Trusted files list(TFL)! Why not ask about adding, at least about files that haven’t digital signature? It’s worth saying that I could add files to my folder that is in PFFL by Total Commander(often used). This is done when Total Commander runs under usual privileges and asks me for administrative privileges(this do often and it’s a usual operation) when I try to add some file to protected folders and I grant their.
For example, imagine such situation. I add my own folder to PFFL. And forgot about this(just imagine, it is a really situation for most users). Some time later I copy some potential malware to this folder. And Comodo automatically place it in TFL!
I’ll move this post to the feedback board where it get’s more exposure.
Let me explain this because you didn’t understand Ronny’s explanation.
Comodo is the nanny of program behaviour not the nanny of user behaviour. It will not allow not trusted program to change other programs. It will allow the user to do such things.
The user is allowed to do all sorts of stupid or dangerous things unknown programs are not allowed to. The user can change one application with the other where an unknown program cannot.
Digitally signed malware is a problem that has been discussed more than a few times.
In its current guise the TVL is not very customisable. There are various topics asking for better customisability in Wishlist - CIS. With a quick search I found How to Avoid the Problem of Trusted Malware via the TVL.
Hash checks have been requested various times as well. I found Hash check for programs with rules already created in Wishlist - CIS with a quick search but there are more to be found.
About files getting added to Trusted Files list. There are Windows system files among them:
Other files that get added were installed with a signed installer. Typical example on my system are the files for the Catatlyst Control Center for ATI/AMD graphics adapters.
Well, but using always Paranoid Mode and sandbox disabled should solve the risk, is it ?
Ronny only said that he hope to get a pop-up alert from Comodo if file, that already in the rules, is modifying.
But he and you don’t want to listen me. I repeat once again:
A key problem – automatic(without any questions) placement of the program in TFL. Being in TFL, the program can replaced any program(the question only in UAC and administarative privileges) without any pop-up alerts. Do you agree?
Because of the absence of check of hashes in Firewall Rules this program(malware) that is in the TFL can silently sends the data through the network, having no firewall rule for itself. How it can do it I wrote above in my posts.
Digitally signed malware is not a single problem! The application can be added to TFL in 2 cases else:
If we choose for application a predefined policy “Installer or Updater” in “Treat As” field of pop-up alert, then all the files created by this applicationwill also be treated as trusted installers. How many usual users choose predefined policy “Installer or Updater”? Does Comodo have such statistics? You install a new and necessary application, you certainly check it on virustotal.com :), found nothing, you have installed it. it works fine and seems to be all is ok! But once application “takes out from wide trouser-legs”… some malware and this malware treated as “Installer or Updater” :o . Do you imagine this? I think only regular clearing of TFL will save from such troubles!
The applications that is copy to Protected Files and Folders list are automatically placed in TFL. At least I observe it when copy a file with Total Commander. This is already the third way to place a malware in TFL. But what else surprises prepares for us Comodo I don’t really know! I consider it is necessary to close these potential leaks.
Nothing interesting in that topic about decisions. There are 2 ways:
Very bad if this have been requested and since not realized!
This is because of predefined policy “Installer or Updater”. Check for interesting how many files in your Defense+ Rules have a predefined policy “Installer or Updater”? Only without a deceit, ok? 
I never said I don’t want to listen to you, I think I agree with you on this ‘theoretical’ issue.
But I’m not Comodo Staff, so I can’t fix the issue, so I can only discuss it here with you and I think we’re done discussing, you made your point.
I think this piece of code handling could be improved, but if you don’t like this behavior there is always the ‘paranoid’ mode for D+ where all this is not valid or true.
CIS is tuned for ‘default’ protection with as little alerts as possible, as soon as this case ends up in the wild they will probably make changes to the default behavior.
Until then I’m afraid you have to run FW Custom and D+ Paranoid.
Going Paranoid will disable the TVL and you will get alerted for each and every program. That will give the control you want.
That is a consequence of having a Trusted Software Vendors list as discussed.
Digitally signed malware is not a single problem! The application can be added to TFL in 2 cases else: 1) If we choose for application a predefined policy "Installer or Updater" in "Treat As" field of pop-up alert, then [i]all the files created by this applicationwill also be treated as trusted installers[/i]. How many [u]usual[/u] users choose predefined policy "Installer or Updater"? Does Comodo have such statistics? :) You install a new, small and usefull application, you certainly check it on virustotal.com :), found nothing, you have installed it. it works fine and seems to be all is ok! But once application [i]"takes out from wide trouser-legs"[/i]... some malware and this malware treated as "Installer or Updater" :o . Do you imagine this? [b]I think only regular purge of TFL will save from such troubles![/b]Despite extensive white listing and sandboxing to make things easier for the end user there is a point where the end user will have to take responsibility at one point.
2) The applications that is copy to Protected Files and Folders list are automatically placed in TFL. At least I observe it when copy a file with Total Commander. This is already the third way to place a malware in TFL. But what else surprises prepares for us Comodo I don't really know! I consider it is necessary to close these potential leaks.Do I understand you correctly that when you copy any file, also unknown ones, with Total Commander that file will be added to TFL?
If it is, have you defined Total Commander as ‘Installer or Updater’? if so then that’s the cause.
Installer or Updater is equal to ‘don’t let CIS interfere with this in any way’. Complete full access to your system.
That is a consequence of having a Trusted Software Vendors list as discussed.So, let help developers to find a consensus. One big TVL is very bad, using "Paranoid Mode" is very uncomfortable for the user. So:
The same rules must be for predefined policy “Installer or Updater”.
Despite extensive white listing and sandboxing to make things easier for the end user there is a point where the end user will have to take responsibility at one point.No. I think this potential dangerous predefined policy "Installer or Updater" must be allowed only for the group "Windows Updater Application" and mandatory with two TVLs(see above).
Do I understand you correctly that when you copy any file, also unknown ones, with Total Commander that file will be added to TFL?When I copy any file by TC to any Protected Folder.
Edit by EricJH: I fixed your quote
No.
I did some testing on my Win 7 x86. I found that when copying files to a protected folder these files only get added to the TFL when Total Commander is running under the Installer/Updater policy.
That seems to suggest there is not a bug but a problem with your configuration ( this is a clean install which only had the update to 2196 through the updater). Can you please double check your D+ Rules and post a screenshot of them?
Thanks, as I believed in fact. It confirm what I always thought about every HIPS: best mode to use them and to be safe is using in the highest level.
The arguments presented against firewall hash checking assume that D+ protects against EXE overwriting by malware. This assumption is not necessarily true. First, the web browser trusted by Comodo can run malware scripts (JavaScript, Flash, etc.) from the internet, so that the browser can become malware. Second, not all people who install Comodo Firewall also install D+. Personally, I find D+'s paranoid mode too noisy and intolerable by my wife, and I don’t trust companies that Comodo trusts, such as Google.
I would like to see Comodo add firewall hash checking so that users can mix Comodo’s Firewall with other security software for a complete solution. This feature would help elevate Comodo’s Firewall to a world-class one.
If an exploit runs also from the trusted browser, Defenes+ should anyway alert with a pop up and ask about. Is it ?
Hello guys and Comodo developers! I would like to introduce CHALeaktest. This is a leak test of Comodo Firewall. And perhaps Comodo developers will pay attention to this problem.
I’d like to remind you 2 problems that can lead to a hole in defense of Comodo and a leak:
Now I don’t want to pay money for certificate and to demonstrate ideal Leak Test, because it is not necessary. How it can be done see here . That’s why let’s assume that we have a digital signing program from vendor that is in the Comodo’s Trusted Venfor List. We can simulate this by manually adding CHALeaktest.exe into the Trusted Files List.
CHALeaktest.exe uses for testing 4 widespread application - Opera, Firefox, Chrome, Total Commander. In real malware this list can be certainly bigger. Besides, smart malware could scan computer for needed applications - those, who have the allowed outgoing TCP connections. This could be done also through reading directly of Comodo’s database or registry or desktop folder.
So, the CHALeaktest 1.0 is released!
Don’t forget to read all instructions before testing(it’s important for correct testing). They are:
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]. 7) Add CHALeaktest.exe into Trusted Files list.
Administrative privileges are necessary for CHALeaktest.exe. For CHALeaktest_na.exe they aren’t necessary. Administrative privileges in Windows Vista and older are asked even for Administaror through UAC. So the user can see that program wanted to do something with administrative privileges. But it’s worth saying that almost all leak tests require administrative privileges or UAC turned OFF. For example Comodo Leak Tests or Proactive Security Challenge 64.
CHALeaktest_na.exe can only be effective for application that are not in system folders. This can be Chrome or Total Commander in this test(not generally :)).
I have tested my leak test in Win7 64bit. But it should work in other platforms WinXP(SP3)+.
Thanks pcflanc.com for public service.
I’m looking forward to your replies and also further discussion.
p.s. English is not my native language :).
[attachment deleted by admin]
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]