Firewall Rules for Changed application

Hello everyone!

I have one little question. I tried to search answer on forum, but may be I missed it.

Let’s imagine such situation:

  1. We have some application. We have some Allow Rules in AppRules for it.
  2. We received “new” version of this application. Builded from sources or upgraded or some how else.
  3. At this moment we receive alerts from D+. We agree to replace it.
  4. After all that “new” application gets access to network via Allow Rules for “prev.” version.

But is it Normal - such behavior?
May be I just want to “replace” application, but also I want to receive alerts from Firewall, because application was changed.

Is it more secure to keep, may be, hash of application for Firewall Rules?

If the path and executable name remain the same, the firewall will use existing rules, regardless of the policy or alert level.

  1. I know how Firewall do his job NOW. I’d like to know - isn’t it a huge security hole?
  2. If we change executable from other OS, will I receive alerts from D+?

I think - best way to keep not only path+name, but hash of file+path+name
With such parameters we can try to stop unwanted activity of replaced, upgraded, etc application. Even replaced from other OS.

Can developers say some words about such situation?

I read some posts about hash and wildcards in Rules.
But still I don’t understand why we should allow network activity for “new” application.
If application was changed - it is a NEW applications. No matter if it has same name and same path.

Without testing, I’m not sure what the limits are, in terms of what is and what is not recognised as a ‘new’ executable.

I only know the rules don’t change because I run several applications that are nightly builds, so the executable changes, for each application, everyday. However, the path and the file name remain the same.

For interest, I just performed a small test on a clean system with a fresh install of CIS. I put D+ in paranoid mode and the firewall in custom policy with alerts on very high.

Then using a zip build of firefox 4.b13pre I created a short-cut on the desktop and launched the application with the profile manager active. I created a profile called test and let the application run. It gave alerts for both D+ and the firewall.

I then replaced the files in the firefox 4 folder with those from firefox 3.6.16pre. Nothing else was changed. I launched the application from the same short-cut and selected the test profile. I did not receive any additional alerts.

That’s as far as my testing went.

Including a file hash might be a useful addition, providing it can be controlled. Being a beta tester, I really don’t want alerts every time something changes. Perhaps a check-box on each application rule to enable of disable the check…

Anyone else?
We need you vision to improove COMODO Products =)

Please calm down MrEngland…

Including a file hash might be a useful addition, providing it can be controlled. Being a beta tester, I really don't want alerts every time something changes. Perhaps a check-box on each application rule to enable of disable the check...

This is a very good idea :-TU
Checking the hash is needed when exiting an application on the Internet. Especially in cases of possible substitution of the application.

I’ll do a cross-post.
Here is bug-report about D+. That Bug + this “issue” can do a data leak from computer without any Alert.

Did you switch to Paranoid mode in your testing to eliminate TVL and white list?

Paranoid mode makes no difference if the path and executable name are the same. Likewise, deleting the vendor from the TVL.

It could be defense+ changing firewall options. Altho people who uses firewall without d+ would be secureless too and maybe its not how comodo programmers like to do it.

When hash changes, throw a new alert Something like Comodo detected exe changed bla bla bla… “keep old rules for this updated app”, “keep old rules for this updated app and dont ask again” (current behaviour). And the options we get normally in a comodo alert (this deletes old rules and create the new one). ← Like current d+ implementation but deleting/updating firewall rules on it.

Egemen stated in the past that the reason for not using hash codes to see if files have changed was because there was sufficient trust that D+ would prevent unauthorized programs from being able to change programs (%Program Files% is a protected folder).

As a test, I installed firefox 4 in the default location. This places the application files in Program Files\Mozilla Firefox. I then ran the application, received firewall and D+ alerts and created a rule for the browser using the default web browser rule. I then replaced the files in the Program Files \Mozilla Firefox with the application files from fireox 3.6. ran the browser and received no additional alerts.

Firewall is in Custom Policy Mode with Alerts on Very High. D+ is in Paranoid mode.

As an additional test, I replaced explorer.exe from default Windows 7 with explorer.exe from Windows 7 SP1, simply by taking ownership and renaming the old file. This process did not raise any alerts.

Granted, I have full access to the PCs and I have administrative control, which is two thirds of the battle.

Thx for testing. It seems there is only a hash check when programs get loaded in memory when CIS is in Training or Clean PC mode:

Image Execution Control is an integral part of the Defense+ engine. If your Defense+ Security Level is set to ‘Training Mode’ or ‘Clean PC Mode’, then it is responsible for authenticating every executable image that is loaded into the memory.

Comodo Internet Security calculates the hash of an executable at the point it attempts to load into memory. It then compares this hash with the list of known/recognized applications that are on the Comodo safe list. If the hash matches the one on record for the executable, then the application is safe. If no matching hash is found on the safe list, then the executable is ‘unrecognized’ and you will receive an alert.

Src: Comodo Help .

As an additional test, I replaced explorer.exe from default Windows 7 with explorer.exe from Windows 7 SP1, simply by taking ownership and renaming the old file. This process did not raise any alerts.
CIS allows users to do such things without alerting. It allows the user to do "stupid things". CIS is the nanny of program behaviour; not of user behaviour.
Granted, I have full access to the PCs and I have administrative control, which is two thirds of the battle.
The same comment as in the above.

No worries, it was just an idle curiosity.

It seems there is only a hash check when programs get loaded in memory when CIS is in Training or Clean PC mode:Src: http://help.comodo.com/topic-72-1-155-1142-Execution-Control-Settings.html .

It makes no difference if I place the firewall and D+ in Training Mode, or if I use Clean PC. Once Firefox 4 has been installed and loaded once, I can replace the entire firefox 4 directory with firefox 3, without additional alerts or changes to the fw/D+ rules.

Interestingly, in the firewall and D+ rules, the icon changed from the standard red and blue fox of firefox 4 to the blue and black globe (nightly Namoroka build) of firefox 3. It also change back when I replaced the files again with firefox 4. Clearly some change is being recognised.

In another test. I installed firefox 4 with the firewall and D+ in safe mode. Because firefox 4 is a recognised application, there were no prompts and no rules were created. I then replaced the contents of the firefox 4 folder with the files from Namoroka and launched the application. This time I received numerous alerts. This is unsurprising, as even though Namoroka is firefox, it’s a nightly build and as such, not recognised.

Following a clean install of firefox 4, I replaced the files with a released build of firefox 3, this time there were no alerts and no rules.

I guess a lot depends on how and when the hash check is performed…

CIS allows users to do such things without alerting. It allows the user to do "stupid things". CIS is the nanny of program behaviour; not of user behaviour. The same comment as in the above.

It’s certainly not difficult to change some core files, in fact it’s almost essential if one likes custom themes. Of course, this could be an easy attack vector, but I assume, if a replacement file were ‘infected’ in some way, it should be picked up one of the suite components on first run…

That aside, I can see a possible benefit in having, at the least, essential core system files employing some kind of additional check, possibly file hashes.

That is expected as FF 3 probably both has a digital signature and may be on the white list.

Interestingly, in the firewall and D+ rules, the icon changed from the standard red and blue fox of firefox 4 to the blue and black globe (nightly Namoroka build) of firefox 3. It also change back when I replaced the files again with firefox 4. Clearly some change is being recognised.
:)
In another test. I installed firefox 4 with the firewall and D+ in safe mode. Because firefox 4 is a recognised application, there were no prompts and no rules were created. I then replaced the contents of the firefox 4 folder with the files from Namoroka and launched the application. This time I received numerous alerts. This is unsurprising, as even though Namoroka is firefox, it's a nightly build and as such, not recognised.
Indeed expected behaviour.
Following a clean install of firefox 4, I replaced the files with a released build of firefox 3, this time there were no alerts and no rules.
Was this in Paranoid or another mode?
I guess a lot depends on how and when the hash check is performed...

It’s certainly not difficult to change some core files, in fact it’s almost essential if one likes custom themes. Of course, this could be an easy attack vector, but I assume, if a replacement file were ‘infected’ in some way, it should be picked up one of the suite components on first run…

If the adapted (infected) theme file would be an executable it would go through the complete vetting as it is an unrecognised file. If it is not an executable only the AV could help here.

That aside, I can see a possible benefit in having, at the least, essential core system files employing some kind of additional check, possibly file hashes.
[/quote]

It was Namoroka, not a release build, so I’d expected to see similar behaviour when I did the test in safe mode.

Was this in Paranoid or another mode?

Safe mode and paranoid mode.