Online_Sword

New Member
Verified
Trusted
version: ESET Antivirus 9.0.349.15 (32-bit)
HIPS mode: Automatic Mode

Now I have established a all-ask rule like this:
Rule Name: 1 - Ask All
Source: All Applications
Target: All Applications
Action: Ask
Application Operation: Modify state of another application

I have also created another rule which allows chrome.exe to modify itself:
Rule Name: 2 - Example Allow Chrome
Source: %ChromePath%\chrome.exe
Target: %ChromePath%\chrome.exe
Action: Allow
Application Operation: Modify state of another application

Note that without Rule 2, I will get an alert generated by Rule 1 each time when I open chrome. So, it is easy to verify whether Rule 2 works or not.

Now the problem is that, in some cases, with Rule 2 enabled, ESET still alerts me that chrome.exe is trying to modify the state of chrome.exe. This implies that in a few cases, Rule 2 does not work.

This is only one example. In fact, ESET also generates such kind of alerts for applications that have also been whitelisted with rules similar with Rule 2. Please note that this problem also happens to the Block rules.

To sum up, I think, in some cases, some of the ESET HIPS rules do not work. I have not found a way to definitely reproduce this issue, so I have not submitted it to the customer service.

Have anyone here also seen this problem ever?
 
  • Like
Reactions: Rishi

Rishi

Level 19
Verified
Trusted
Do you have logging enabled? Looking at the HIPS logs will help pinpoint what's happening per execution basis.It will also be useful in reporting it on ESET forums if inconsistency is found. On a side note, I am not sure chrome with the amount of child processes it opens is ideal for testing, could you try the same thing with a gecko based browser or something simpler?
 
H

hjlbx

version: ESET Antivirus 9.0.349.15 (32-bit)
HIPS mode: Automatic Mode

Now I have established a all-ask rule like this:
Rule Name: 1 - Ask All
Source: All Applications
Target: All Applications
Action: Ask
Application Operation: Modify state of another application

I have also created another rule which allows chrome.exe to modify itself:
Rule Name: 2 - Example Allow Chrome
Source: %ChromePath%\chrome.exe
Target: %ChromePath%\chrome.exe
Action: Allow
Application Operation: Modify state of another application

Note that without Rule 2, I will get an alert generated by Rule 1 each time when I open chrome. So, it is easy to verify whether Rule 2 works or not.

Now the problem is that, in some cases, with Rule 2 enabled, ESET still alerts me that chrome.exe is trying to modify the state of chrome.exe. This implies that in a few cases, Rule 2 does not work.

This is only one example. In fact, ESET also generates such kind of alerts for applications that have also been whitelisted with rules similar with Rule 2. Please note that this problem also happens to the Block rules.

To sum up, I think, in some cases, some of the ESET HIPS rules do not work. I have not found a way to definitely reproduce this issue, so I have not submitted it to the customer service.

Have anyone here also seen this problem ever?
You have to make sure Rule 2 has priority over Rule 1.

In HIPS rules pane, make sure Rule 2 is above Rule 1; if I recall correctly, ESET HIPS rules are applied in order from top => bottom.

If this is still how ESET HIPS rules priority works, and you make the above change and problem persists, then it is likely a bug.

Re-reading your post a few times, it appears to be a potentially more serious issue.
 
Last edited by a moderator:

Online_Sword

New Member
Verified
Trusted
Do you have logging enabled? Looking at the HIPS logs will help pinpoint what's happening per execution basis.It will also be useful in reporting it on ESET forums if inconsistency is found.
No, I did not enable it in the past. But now I have enabled it for Rule 1 and Rule 2. I will post the log here when this bug occur again.

On a side note, I am not sure chrome with the amount of child processes it opens is ideal for testing, could you try the same thing with a gecko based browser or something simpler?
It sounds reasonable. However, this bug rarely occurs, so I have to use an application that I launch many times every day to test it. Chrome is the only application that satisfies this requirement.

ESET HIPS rules are applied in order from top => bottom
The priority sequence of ESET HIPS is:
  • Block -> Allow -> Ask
  • Specific Application -> All Application
So, theoretically, Rule 2 should always have a higher priority than Rule 1.

it appears to be a potentially more serious issue
I think so, especially when sometimes the Block rules do not work. :(
 
  • Like
Reactions: Rishi and frogboy
H

hjlbx

No, I did not enable it in the past. But now I have enabled it for Rule 1 and Rule 2. I will post the log here when this bug occur again.



It sounds reasonable. However, this bug rarely occurs, so I have to use an application that I launch many times every day to test it. Chrome is the only application that satisfies this requirement.



The priority sequence of ESET HIPS is:
  • Block -> Allow -> Ask
  • Specific Application -> All Application
So, theoretically, Rule 2 should always have a higher priority than Rule 1.



I think so, especially when sometimes the Block rules do not work. :(
Waiting for next version of ReHIPS; depending upon what @Recrypt integrates and can accomplish - ReHIPS might be permanent replacement for security suite HIPS.

I sure hope that it is...
 
  • Like
Reactions: Online_Sword

Online_Sword

New Member
Verified
Trusted
@Rishi

It seems that enabling the log for HIPS might not be an efficient way to solve this problem. I have only enabled it for several minutes, but Rule 2 has already generated 1640 log items ! I cannot imagine what would happen if I enable it for a whole day:D
 
  • Like
Reactions: Rishi

Rishi

Level 19
Verified
Trusted
I think you should just keep the logs enabled and when the bug occurs, just take the screenprint of the most recent entries, that you should have something to show to the guys at ESET , and the rest of the logs can remain for 1-2 weeks until this is resolved? Since the frequency of its occurence is low and we don't know what reproduces it.Just my suggestion.
 
  • Like
Reactions: Online_Sword

Online_Sword

New Member
Verified
Trusted
@Rishi

Thank you for your advice.:) I would try. But I still worry about the hard disk space that will be used by the huge number of log items...I am using an old laptop at my hometown. The capacity of Partition C is only 60 GB...
 
  • Like
Reactions: Rishi

Rishi

Level 19
Verified
Trusted
Can you Pm me with the ESET settings and chrome version/extensions/settings, let me see if I can replicate the issue over the weekend?
 

Online_Sword

New Member
Verified
Trusted
This issue appears again, as shown in the following screenshot:


I have exported the logs corresponding to Rule 1. It seems that Rule 1 was triggered about 149 times in several seconds. The problem is that the log file is in Chinese. After my vacation, I will install the English version of ESS on VM and generate some new logs in English.
 
  • Like
Reactions: Rishi

Rishi

Level 19
Verified
Trusted
I did not get anything over the weekend, so I am going to try for a whole week.Switched to using chrome full time, hopefully something will be logged.
 
  • Like
Reactions: Online_Sword

chrcoluk

Level 1
I just did the same thing, 2 rules.

One to prompt on application starting another application.
One to allow chrome to launch another chrome process.

When I clicked the link above to go back to post list I was prompted to allow chrome to start a new child process, so I have the same issue it seems.

nod32 v8.