CIS overrules user defined HIPS Custom Rulesets for Trusted Applications

Comodo Internet Security - CIS Resolved/Outdated Issues - CIS
1

V12.2.2.7036 (Firewall only) Windows 7 Ultimate 64-bit

Below behavior applies to Trusted applications in general.

HIPS Settings: Enabled in Safe mode

Steps to reproduce:

1) Go to “HIPS->HIPS Rules” and add a Custom Ruleset for “C:\Windows\System32\notepad.exe” and set all “Access Name->Action” to “Block” (so 14 “Action->Block” in total) and leave all “Exclusions” and “PROTECTION SETTINGS” to default setting.
See attached image “HIPSCISOverrulesCustomRule1.jpg”

2) Start “C:\Windows\System32\notepad.exe” and type as quickly as you can about 30 to 40 short lines containing some random text.

3) Close notepad and select “Don’t Save” the changes (just discard what has been typed).

4) Go back to the HIPS Custom Ruleset for “C:\Windows\System32\notepad.exe” and check if all “Access Name->Action” items are still set to “Block” (it should be, still 14 “Action->Block” in total).
See attached image “HIPSCISOverrulesCustomRule1.jpg”

5) Now set “Access Name->Keyboard->Action” to “Ask” (leaving 13 “Action->Block” with 1 “Action->Ask”).
See attached image “HIPSCISOverrulesCustomRule2.jpg”

6) Do the same as stated in step 2)

7) Do the same as stated in step 3)

8) Go back again to the HIPS Custom Ruleset for “C:\Windows\System32\notepad.exe” and check again if all “Access Name->Action” items are still set to “Block” except for “Access Name->Keyboard” which should be set to “Ask”.

Now, nearly all “Access Name->Action” settings have been overrruled / modified / altered by CIS. There is only 3 “Access Name->Action->Block” items left and everything else is set by CIS to “Allow”.
See attached image “HIPSCISOverrulesCustomRule3.jpg”

When all the above steps is repeated for an Unrecognized application then the result of step 8) is the same as shown in attached image “HIPSCISOverrulesCustomRule2.jpg” except for “Access Name->Keyboard-Action” which would then be set to “Allow” when the user chooses “Allow” and “Remember” from the HIPS popup Alert “Notepad wants to access the Keyboard directly”.

Unexpected result: CIS overrules / modifies / alters a user defined HIPS Custom Rulesets for Trusted applications.
The user defined Custom Ruleset is not static but volatile and doesn’t work the way the user would expect it to work.
When the user changes one “Access Name->Action” setting this may result in CIS changing many other "Access Name->Action’ settings as well which is unwanted.

Expected result: A user defined HIPS Custom Ruleset for Trusted applications should be static and not be overruled / changed / altered or modified by CIS.
A user defined HIPS Custom Ruleset for Trusted applications should work in the same way as they do work for unrecognized applications.

2

settings in images can cause block functions in applications;
CIS in settings default protected good we PCs (computer)…

Sorry my english

3

Does it also happen with non-MS signed applications? This could possibly be happening due to MS signed executables being hardcoded to be trusted by CIS as you already know.

4

Hi Liosant,

Thank you for your reply, I appreciate it :-TU

I’m fully aware that changing HIPS Rules can lead to block functions in applications and possibly lead to application instability and as such novice users should certainly not do this. For expert-users (or power-users or advanced-users whatever you call them) like me however there are sometimes reasons to tweak HIPS rules for applications and as demonstrated in the bug report CIS won’t allow this as it overrules the user defined HIPS Custom Rules for Trusted applications.

The test case that I used in my bug report (setting all “Access Name->Action” to “Block”) was just chosen for demonstration purpose only.
This is something I normally won’t do, I only make small tweaks but unfortunately CIS won’t allow me to do that.

5

Before I submitted this bug report I tested the following cases also:

Case 1)

Created a copy of “C:\Windows\System32\notepad.exe” along with it’s locale into a user sub-directory and made notepad++ unsigned by changing a few harmless string bytes in notepad.exe.

Now with auto-containment disabled and performing the exact same steps as described in the first post:

Running unsigned notepad with File Rating set to Trusted : result of step 8 ) = exactly the same as reported in step 8 ) in the first post.
Running unsigned notepad with File Rating set to Unrecognized : result of step 8 ) = 13 “Block” and 1 “Allow” (after answering the HIPS popup Alert)

Case 2)

Using a non-MS signed executable “notepad++.exe” with File Rating Trusted per default and performing again the exact same steps as described in the first post, the result is as follows:

Note: For this test to work “notepad++.exe” HIPS Custom Rule “Access Name->Windows/WinEvent hooks” has to be set to “Allow” otherwise “notepad++.exe” won’t start.

Running signed notepad++ with File Rating set to Trusted : result in step 8 ) = exactly the same as reported in step 8 ) in the first post.
Running signed notepad++ with File Rating set to Unrecognized : result in step 8 ) = 12 “Block” and 2 “Allow” (after answering the HIPS popup Alert)

Note: The result is the same as in case 1) except that 1 “Allow” had to be set to “Access Name->Windows/WinEvent hooks” to allow notepad++ running, see the note above.

So overall conclusion:

CIS overrules user defined HIPS Custom Rulesets for Trusted Applications whether they are MS or non-MS applications.

6

Sounds to me that you have create rules for safe applications enabled and verbose mode alerts disabled, which means it is expected behavior.

7

I think that’s only half correct.
Please see attached image which shows the HIPS settings that I normally use and which have been used when I conducted the above tests.

8

That fact that create rules for safe applications enabled makes this a non-issue as it is doing what is it is designed to do. If a trusted application has any access right set to ask, then HIPS learns and allows the action when create rules for safe applications is enabled or if you are in silent mode.

9

I agree that HIPS learns when create rules for safe applications is enabled and that it allows only that particular action having an access right set to Ask. However, I don’t get the logic that HIPS also changes the other actions having access rights set to non-Ask as can be seen from the attached images in the first post.
To put it even stronger, when setting all action rights for notepad.exe to Ask but only Keyboard to Allow than nothing changes at all after running notepad. The custom rule for notepad.exe keeps all access rights set to Ask and the access right for Keyboard to Allow.
Notepad only needs the Allow rule for direct Keyboard access, it does not need any other access rights to run, try it yourself I would say.

Where is the logic here ?!?!

Back to the bug report, to me it is still an issue.

10

Because verbose mode doesn’t apply to auto created rules, which means access rights are grouped together when verbose mode was off in the past, so auto created rules for safe applications works as if HIPS is in non-verbose mode. Access to com/registry/files is one group and all other access rights are in another group.

11

So to resolve this issue Verbose Mode should also apply to Create Rules For Safe Applications so that no grouping occurs anymore.

The following idea would be a possible and practical solution to this issue.

When a Safe Application is run and no custom rule exists for it yet (or the custom rule was deleted by the user) then HIPS creates a new custom rule for it with all access rights set to Ask.
Now when during execution time the Safe Application needs certain access rights then HIPS sets the corresponding access right from Ask to Allow silently but not touching any access rights set to non-Ask.
On successive runs when the Safe Application may request new access rights then, for those access rights which are still set to Ask, those access rights will be also set from Ask to Allow silently but again not touching any non-Ask access rights.

I think this comes close how Verbose Mode works, it would be a nice workable solution to solve this bug.

12

Is there any chance that this issue will be fixed in the next release?

13

To quote myself, any feedback on this perhaps?

14

No there is no value in making auto created rules to be made using very specific verbose rules as it would cause significant performance issue than it already does.