Serious Discussion Why does the Comodo "Disappearing HIPS rules" bug require a complete source code rewrite?

[Andy Ful]

The "Create rules for safe applications" rule is useful for experienced users, but most don't need it. If I remember well, many rules can affect Comodo's performance: navigating, working with modules, etc. The many HIPS rules were also one factor in the "disappearing HIPS rules" bug. These were also reasons Comodo later disabled the discussed rule.

Yes. Most users (also experienced ones) do not need Paranoid HIPS. The rule "Create rules for safe applications" is considered on the Comodo forum as the main reason for HIPS problems. My test is not a recommendation for using Paranoid HIPS or the rule "Create rules for safe applications". It is a continuation of the discussion in this thread.

In this thread, we suspect that the source of the HIPS rewriting problem is an unsafe and unoptimized way of storing HIPS settings in the Windows Registry. The author of the thread suggested that it is easy to reproduce the issue of disappearing HIPS rules.
I will continue the test to see if this is true on the modern computer. So far, I noticed some lost rules related to rule overwriting by "Create rules for safe applications".

On my computer, the rules are written for about 1-2 seconds, depending on the number of rules. The Pico's test suggests that on some computers, the writing can last much longer, which can be a reason for HIPS disappearing rules on shutdown.

 

[Trident]

On my computer, the rules are written for about 1-2 seconds, depending on the number of rules. The Pico's test suggests that on some computers, the writing can last much longer, which can be a reason for HIPS disappearing rules on shutdown.

But I was right in this case that bringing the write time down will solve the issue.

 

[Andy Ful]

But I was right in this case that bringing the write time down will solve the issue.

The write time must be sufficiently short to avoid shutdown issues that we discussed here.
The shorter the write time, the smaller the chances for HIPS rewriting problems.
I am not sure if 2 seconds of write time is sufficiently short. In VM, I use

• 8 GB RAM 3200 MT/s,
• 2 CPU cores 3.90 GHz,
• SSD speed writes up to 5000 MB/s.

 

[Trident]

The write time must be sufficiently short to avoid shutdown issues that we discussed here.
The shorter the write time, the smaller the chances for HIPS rewriting problems.
I am not sure if 2 seconds of write time is sufficiently short. In VM, I use 8 GB RAM 3200 MT/s, 2 CPU cores 3.90 GHz, SSD speed write 5000 MB/s.

Let me try on my machine.
Can you please provide a link to the installer you used?

 

[Trident]

Yes, I am able to reproduce and confirm the bug exists.

A few observations from Comodo that I made during this test:

• HIPS is anyway slow to initialize. There is over a 30 second period from the boot of the system to the rule enforcement and monitoring
• Comodo does not have any ELAM configuration whatsoever. It will be unable to do anything else with ELAM apart from using the ETW (recording the boot configuration)
• The write time on my system is not super slow (in line with @Andy Ful), the Comodo HIPS rules prior to the loss were 3.2 MB. Comodo does not allow browsing, but I used another method to rip the rules. After reboot, the rules drop down to 2.4 MB instead of increasing the size. This confirms clearly that there is data loss.
• The system feels slow and buggy. Upon restart, it was stuck on logging in (after the pin entry), I had to hold the shutdown button and try again. Next, the shell was unresponsive for a good 30-40 seconds before over 20 alerts started popping up.
• Various Comodo UI bugs
• Comodo using its kernel HIPS driver was able to halt the shutdown indefinitely, till I respond to a logonui.exe alert… this means that it will be able to halt the shutdown till it writes its rules with no issues whatsoever. It doesn’t have to use the standard user mode calls to the SCM.

The Comodo HIPS module in this state can only be considered unusable and it is best that it remains disabled.

I asked Gemini to compare the old and new post-reboot configs:

Based on your premise that reg.reg is the new file and reg2.reg is the old one, here is the focused analysis of the HIPS policy.

To answer your main question directly: Yes, there is 100% data loss.

This is not a merge or an update. The new file (reg.reg) completely replaces the old HIPS policy set with a new, different one. The 71 custom policies from reg2.reg are gone and have been replaced by 29 new policies in reg.reg.

Outline of All Differences​

The only section that differs between the two files is [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\CisConfigs\0\HIPS\Policy].

All other HIPS sections, such as <span>\HIPS\Rules</span> and <span>\HIPS\Sets</span> , are identical in both files. This means the definitions of the rules haven't changed, but the list of applications they apply to has been completely swapped.

---

Old HIPS Policy (reg2.reg)​

This file defines 71 policies (numbered 0 to 70).




Here are the first few policies from this file as an example:

• 
  
  Policy <span>\0</span>: <span>C:\\Windows\\SysWOW64\\runonce.exe</span>
  
  
  
  
• 
  
  Policy <span>\1</span>: <span>C:\\Program Files\\WindowsApps\\Microsoft.WidgetsPlatformRuntime...\\WidgetService.exe</span>
  
  
  
  
• 
  
  Policy <span>\2</span>: <span>C:\\Program Files\\WindowsApps\\MicrosoftWindows.Client.WebExperience...\\Dashboard\\Widgets.exe</span>
  
  
  
  
• 
  
  Policy <span>\3</span>: <span>C:\\Windows\\System32\\lsass.exe</span>
  
  
  
  
• 
  
  (...and so on for 67 more policies, ending with Policy <span>\70</span> for <span>dragon_helper.exe</span> )

---

New HIPS Policy (reg.reg)​

This file defines a completely different set of 29 policies (numbered 0 to 28).




Here are the first few policies from this file:

• 
  
  Policy <span>\0</span>: <span>C:\\Windows\\regedit.exe</span>
  
  
  
  
• 
  
  Policy <span>\1</span>: <span>C:\\Windows\\System32\\consent.exe</span>
  
  
  
  
• Policy \2: C:\\Windows\\System32\\taskmgr.exe
• Policy \3: C:\\Windows\\System32\\MoUsoCoreWorker.exe
• (...and so on for 25 more policies, ending with Policy \28 for CisNotifier.exe)

Conclusion​

If you apply reg.reg (the new file), you will lose the 71 specific HIPS application policies that were in reg2.reg (the old file) and replace them with the 29 new policies.

 

[Andy Ful]

@Trident,

I used this link:

Thanks for downloading Free Antivirus from Comodo

Thanks for Downloading Free Antivirus from Comodo. Protect your computer against Virus, Malware and Spyware

antivirus.comodo.com

Did you use the recommended way?
Training Mode (for a while, a few reboots) >> Paranoid Mode (for a while, a few reboots) >> enable "Create rules for safe applications"

What is the time of applying HIPS rules (time of closing HIPS window)?

 

[Trident]

@Trident,

I used this link:

Thanks for downloading Free Antivirus from Comodo

Thanks for Downloading Free Antivirus from Comodo. Protect your computer against Virus, Malware and Spyware

antivirus.comodo.com

Did you use the recommended way?
Training Mode (for a while) >> Paranoid Mode (for a while) >> "Create rules for safe applications"

What is the time of applying HIPS rules (time of closing HIPS window)?

I did use this way, I put it in training mode for a while and opened a few apps from the start menu to create at least some rules.

Later on I switched to paranoid mode and restarted.

Then I made the previous post.

I then reinstalled Comodo and tried with paranoid mode directly. Opening the calculator produced around 3 alerts.
Despite the rules being lost, I did not see these alerts anymore. The “create rules for safe apps” was on the entire time. Could it be that the first time it had no connection to check and establish what was safe? No idea.

It looks to me that there are severe logical flaws with the entire rules handling system. Starting from the write, to the storage location to the handling, the initialisation (sometimes slow, sometimes quick), nothing works properly and as expected.

The window closure, I did not use scientific methods to measure the closing period but it feels like approximately 2 seconds.
I didn’t do few reboots every time though, just one…

 

[Andy Ful]

On my VM system starts in 30s (25s to sign in screen) - but I use Comodo Firewall with Microsoft Defender and SAC. The HIPS rules are applied immediately on Windows start - I use bat file to run blocked applications.
However, I had one problem with restarting Windows (hanged on shutdown). HIPS still not corrupted - I can open apps and run LOLBins which were initially alerted by HIPS, and LOLBins previously blocked are still blocked.

 

[Trident]

On my VM system starts in 30s (25s to sign in screen) - but I use Comodo Firewall with Microsoft Defender and SAC. The HIPS rules are applied immediately on Windows start - I use bat file to run blocked applications.
However, I had one problem with restarting Windows (hanged on shutdown). HIPS still not corrupted - I can open apps and run LOLBins which were initially alerted by HIPS, and LOLBins previously blocked are still blocked.

Can you actually see the rules in Comodo settings window?
If you export that section which seems to hold the rules, can you also see them in the reg file?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\CisConfigs\0\HIPS\Policy]

 

[Andy Ful]

I did use this way, I put it in training mode for a while and opened a few apps from the start menu to create at least some rules.

Later on I switched to paranoid mode and restarted.

Then I made the previous post.

This is not recommended. Also in my case it caused serious problems. The Paranoid Mode must be applied only after a few reboots.

I then reinstalled Comodo and tried with paranoid mode directly. Opening the calculator produced around 3 alerts.
Despite the rules being lost, I did not see these alerts anymore. The “create rules for safe apps” was on the entire time. Could it be that the first time it had no connection to check and establish what was safe? No idea.

This is not recommended as in the first test.

It looks to me that there are severe logical flaws with the entire rules handling system.

Yes. However, the method used by me seems to work (for now) with some minor problems (see my previous post).

 

[Trident]

Yes. However, the method used by me seems to work (for now) with some minor problems (see my previous post).

I will try this method with the few reboots later.

The recommended tuning period for this kind of tools is 7 days.

I’d probably keep Comodo for 7 days and we’ll see.

 

[Andy Ful]

Can you actually see the rules in Comodo settings window?
If you export that section which seems to hold the rules, can you also see them in the reg file?
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CmdAgent\CisConfigs\0\HIPS\Policy]

Yes, I have over 100 rules including rules that blocks 2 LOLBins.
I can see 112 rules under that key, however they are protected from reading.

 

[Trident]

Yes, I have over 100 rules including rules that blocks 2 LOLBins.
I can see 112 rules under that key, however they are protected from reading.

Yeah. They did not protect from export though.

 

[Andy Ful]

I will try this method with the few reboots later.

The recommended tuning period for this kind of tools is 7 days.

I’d probably keep Comodo for 7 days and we’ll see.

You should also remove your custom rules before starting training mode and not enable "Create rules for safe applications" (it was not enabled by default in my installation.)

 

[Trident]

You should also remove your custom rules before starting training mode and not enable "Create rules for safe applications" (it was not enabled by default in my installation.)

I did one reboot with this disabled and the rules remained… I think only when this is enabled, the corruption happens.

But then in paranoid mode, it would probably flood with alerts…

If it is not creating rules for safe applications

 

[Andy Ful]

I did one reboot with this disabled and the rules remained… I think only when this is enabled, the corruption happens.

But then in paranoid mode, it would probably flood with alerts…

If it is not creating rules for safe applications

I my test, after Training Mode and enabling Paranoid Mode, there were some alerts but not many. Of course the alert can happen if you run something for the first time. Paranoid Mode is not suited for normal usage.

 

[Pico]

The CIS HIPS security levels are offered by Comodo as presented in CIS User Guide, see screenshot.

Users can decide themselves or being advised what is good for them and what HIPS settings they want or prefer to use for normal use. It's up to them and nobody else to make that decision what settings to use. Nobody should have to tell them don't use this or that because it doesn't work. If things don't work as expected or as presented by Comodo than that's a bug and should be fixed one way or the other. If something is broken than fix it.

Unfortunately the HIPS bug is still present in all three HIPS security levels.

 

[Andy Ful]

@Trident,

I used the same VM cloned on HDD which is 30 times slower than my SSD. However, the HIPS windows closes as fast as in the VM on SSD.
This suggests that rewriting HIPS rules is done in registry cache in memory (depends on RAM speed).

I also noticed that the HIPS window is now closed in 2 seconds (1 second longer than after installation), but the rule added via HIPS alert is activated faster (1 second or faster).

I made a simple test.

1. Opened CMD console, executed the CmdLine: start certutil , and allowed CMD to execute Certutil.
2. Removed the rule for Certutil.
3. Opened Explorer, executed Certutil. Comodo showed the alert but did not chose any options (the alert was not closed).
4. In the CMD console, I wrote start certutil but did not execute it.
5. Next, I chose to block Certutil in the Comodo alert and immediately executed the Certutil in CMD console.
6. Two Certutil blocks were present, even if the time between those two events was about 1 second. I did not manage to do this faster.

My computer is too fast to be sure if this difference is significant. It would be interesting to make similar test on a slower computer to exclude the possibility that rules added via Comodo alerts (no full rewrite) are written differently than via HIPS window (full rewrite).

 

[rashmi]

I did the trick with TaskManager to see the Desktop and disabled the setting "Create rules for safe applications" and enabled Training Mode.
After a successful restart, I enabled Paranoid Mode again. This finally worked, Windows restart and sign-in were successful.

In the end, I enabled the setting "Create rules for safe applications" and restarted Windows. No problems.
CF works with Internet Security config + Paranoid HIPS + enabled "Create rules for safe applications".
I did not encounter any HIPS corruption in my whole test (so far). We will see if this happy scenario will continue.

Conclusion (so far).
The best order of action for using Paranoid Mode:
Training Mode for a few days ----> Paranoid Mode for a few days -----> enabling "Create rules for safe applications"

I think you could successfully boot the system because you enabled Training Mode.

I believe the "Create rules for safe applications" rule has no effect with HIPS on Paranoid Mode, as Comodo doesn't "automatically" create rules for safe applications with Paranoid HIPS; you "manually" create rules for safe/unknown apps through HIPS alerts.

 

[Andy Ful]

I think you could successfully boot the system because you enabled Training Mode.

Yes, I intentionally did it because without it, Windows did not start properly in my test.

I believe the "Create rules for safe applications" rule has no effect with HIPS on Paranoid Mode, as Comodo doesn't "automatically" create rules for safe applications with Paranoid HIPS; ...

You are wrong. I already confirmed that it can overwrite existing rules.
For example, I added Explorer to the Allowed Application group, applied the settings, and checked that it is saved properly. Next, I ran Explorer (no alerts) and rechecked the settings. The setting for Explorer changed from Allowed Application to Custom ruleset.