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

Several users have reported that this issue only occurs when the “Create rules for safe applications” option is enabled. The recommended workaround is to uncheck this option, which prevents HIPS from automatically creating rules and appears to stop the bug from being triggered. However, this means you will need to manually create rules for new applications, a method typically preferred by advanced HIPS users. If you are not an advanced user, it may be worth reconsidering whether HIPS is necessary for your setup, as manual configuration can be complex and may affect usability.

It is also strongly recommended to back up your rules regularly. You can use the Export feature to save your complete CIS configuration (including HIPS and Firewall rules) to a .cfgx file. If your rules ever disappear, use the Import feature to restore your saved settings from this file. It’s a good practice to perform a backup after every significant change to your rules to avoid data loss.

At this time, it remains unclear whether this bug affects all users who enable “Create rules for safe applications”, or only those with specific system configurations or conflicting third-party software. Further user reports and testing may help narrow down the cause.

Although discussions continue regarding potential solutions, the guidance provided by the Comodo staff has been accurate. HIPS is an advanced security feature intended for users with a thorough understanding of both the application and the operating system. While this does not excuse the existence of the bug or the duration it has remained unresolved, excessive concern or overreaction is unwarranted.
 
  • Like
Reactions: caleche
The HIPS rewriting bug is mainly present when the “Create rules for safe applications” option is enabled (this was also confirmed by @GenV).
G

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

I hope that this thread would close quickly as it seems that it only produces more flame mostly irrelevant of the topic
It seems that discussion is on right track again.

I have checked HIPS rules cleanup bug with latest CIS build, and yes, it's still present with enabled rules auto-creation for safe apps. It definitely shouldn't be used.
However, HIPS rules list on XCS is not resetting on reboot, so it definitely doesn't require full HIPS rewrite that @bazang is constantly referring to.
CIS and XCS are different products, they had same codebase in the past (and would in...
  • Like
  • Hundred Points

It is understandable, because Comodo is allowed to silently add some rules during the shutdown, which often corrupts HIPS settings.
For similar reasons, corruption can happen (rarely) when configuring HIPS manually, and system crashes.
 
  • +Reputation
Reactions: simmerskool and Trident
caleche said:
Maybe we should list 'pretending to care' as a feature—at least it doesn’t disappear after a reboot.
Click to expand...
This does not serve any ego-driven agenda or support a particular narrative. Having not used this product since it was merely a firewall and not a full suite, my sole intention here is to present facts objectively, without bias or any other interests influencing my perspective.
 
  • Like
Reactions: caleche
Andy Ful said:
The HIPS rewriting bug is mainly present when the “Create rules for safe applications” option is enabled (this was also confirmed by @GenV).
G

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

I hope that this thread would close quickly as it seems that it only produces more flame mostly irrelevant of the topic
It seems that discussion is on right track again.

I have checked HIPS rules cleanup bug with latest CIS build, and yes, it's still present with enabled rules auto-creation for safe apps. It definitely shouldn't be used.
However, HIPS rules list on XCS is not resetting on reboot, so it definitely doesn't require full HIPS rewrite that @bazang is constantly referring to.
CIS and XCS are different products, they had same codebase in the past (and would in...
  • Like
  • Hundred Points

It is understandable, because Comodo is allowed to silently add some rules during the shutdown, which often corrupts HIPS settings.
For similar reasons, corruption can happen (rarely) when configuring HIPS manually, and system crashes.
Click to expand...
Yes, it further confirms what I suspect, that on shutdown, the lengthy and slow writer is invoked. Either deletion happens first before a full rewrite (which if you are rewriting the whole state, you just have no other option) or erroneous write causes corruption (for example a rule with missing information) and later on, some health check/integrity check deletes all rules because this is the repair mechanism.
In both cases, it can be configured on shutdown to not create anymore rules.
The shutdown is anyway communicated to Comodo and the writer at the very top can be configured to just exit, returning true (so it is not called again and again).

Problem is with 40s write, the rule writing may have started way before the shutdown is initiated. In this case your backup option is much more reliable. But it has to be executed with registry transactions (or some proprietary logics that perform incremental writing). So what is the difference in this case between creating the backup function and driver, and updating the writer to use the same APIs?
 
Last edited:
  • +Reputation
Reactions: simmerskool
Pico said:
Who would apply for a job to mess with spaghetti...
Click to expand...
A developer has no problem with spaghetti and stoically calls it "software":

software-latest.gif
 
  • Like
  • HaHa
Reactions: Halp2001 and Trident
Trident said:
So what is the difference in this case between creating the backup function and driver, and updating the writer to use the same APIs?
Click to expand...

If HIPS is corrupted at shutdown, it is also corrupted on the Windows startup. If not corrected at boot time, it can crash the system.
 
  • +Reputation
  • Like
Reactions: simmerskool and Trident
Andy Ful said:
If HIPS is corrupted at shutdown, it is also corrupted on the Windows startup. If not corrected at boot time, it can crash the system.
Click to expand...
I'm aware. But if you can execute the backup properly with no corruption than what is stopping you from executing the writer to the same standard? This is my question which in this discussion despite many posts back and forth (and heavy AI invocation) still remains unanswered.

Or is there some restriction that I am not aware of (such as "developers cannot modify writing functions once software is compiled, they should only add additional functions")?

The problem is the long writing time, as confirmed by INDISPUTABLE evidence already provided earlier.
If the writing time is reduced, the problem will disappear.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Pico said:
Doesn't matter, all HIPS modes are affected by the bug:
- Paranoid Mode
- Safe Mode
- Training Mode
Click to expand...
It will be the case because regardless whether the registry operations time is 10 seconds (250 rules) or ~40 seconds (1000 rules rough calculation) WIndows will not wait neither 10, nor 40 on shutdown. It will terminate the Comodo processes and threads like they are nothing.

The only way to avoid that is to optimise the write and ensure for 1 or for 5-10 rules, it takes milliseconds (which is the acceptable time on a modern system). Then, Comodo can ask for Windows to wait till it writes its final rules and exit (as it is exiting now).

That's all that is needed, based on evidence and information provided by you, including a screenshot.
 
  • Like
  • +Reputation
Reactions: simmerskool, Andy Ful and Pico
Trident said:
I'm aware. But if you can execute the backup properly with no corruption than what is stopping you from executing the writer to the same standard?
Click to expand...

I tried to find out the mitigation that assumes as little as possible, so I did not assume that all backups can be created without corruption.

Trident said:
If the writing time is reduced, the problem will disappear.
Click to expand...

It is also an assumption, which can be true or not. However, it is probably worth trying.
 
Last edited:
  • +Reputation
  • Like
Reactions: simmerskool and Trident
I did a test on my end to see the performance difference of registry interaction APIs.

API similar to Comodo APIs performance on my system:

Write 1000 keys, one thread: ~6 seconds
Write 1000 keys, multi-threaded at 8 threads (1 for every logical core): just 2 seconds speed-up, ~4 sec

Registry transactions (to the already written keys, add 10 keys):

Modify 10 keys: ~49 ms
Add 10 keys: ~2 seconds -> the preparation for atomic write of this api takes long. However, it is likely that Windows can let Comodo save its work.
Reading: ~ 11ms

The same (10 keys operation with 5 values each) executed to a json file with light encryption applied after:

Writing time: ~ 78 ms
Modificattion time: ~ 31 ms
Reading time: ~ 40ms (delayed due to encryption which in real world Comodo probably will apply). In registry there is no encryption, hence reading times are way shorter.

Performing such operations in files is much more efficient.

In addition, instead of a full state rewrite, Comodo can just add the key with the necessary values. A full state rewrite is not necessary.

From the above it can be concluded the registry is not the best place to store massive amounts of data.
Hence, the best design is for the massive amounts of data to go in file and the HIPS driver can delay the start of certain services till the Comodo Service parses the rules and says it is safe to release the block.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Pico said:
Doesn't matter, all HIPS modes are affected by the bug:
- Paranoid Mode
- Safe Mode
- Training Mode
Click to expand...
It does matter though. If the user disabled "Create rules for safe applications" this is how it effects each Mode.

Paranoid mode (The bug is fixed, and the mode operates exactly as designed (manual control).

Safe Mode (The bug is fixed, but the mode's primary purpose (auto-allowing "safe" apps) is disabled, making it behave like Paranoid Mode.)

Training Mode (The bug is fixed, and the mode should still auto-allow all user activity as intended)
 
Trident said:
Performing such operations in files is much more efficient.
Click to expand...

It is hardly possible to check how long it would last in the case of Comodo HIPS settings, especially at shutdown.

However, there is another problem. Suppose that you could reduce the write time to 5 seconds. What does happen if Comodo tries to write on shutdown a few settings one by one?
Yes, many users will choose to close running processes, and this can often cause HIPS corruption.
 
  • +Reputation
  • Like
Reactions: simmerskool and Trident
Andy Ful said:
It is hardly possible to check how long it would last in the case of Comodo HIPS settings, especially at shutdown.

However, there is another problem. Suppose that you could reduce the write time to 5 seconds. What does happen if Comodo tries to write on shutdown a few settings one by one?
Yes, many users will choose to close running processes, and this can often cause HIPS corruption.
Click to expand...
5 seconds is still a lot, the only viable way to execute is to bring down the write time to milliseconds. Even one second is already too much.

The SCM has a variable timer of few seconds anyway. As soon as it sends the SERVICE_CONTROL_SHUTDOWN, Comodo needs to quickly write the last rule(s). If the write takes milliseconds which is achievable, this is enough time.
After that, the service needs to stop.

From my calculation, 14k writes for 1000 rules, every key contains roughly 14 values. My test was based on 5 values. When an array of strings is dumped at once, it hardly matters.

For inefficient operations in the registry, it makes big difference.

Edit: I just tried 10 keys with 14 values each using the Comodo chosen API and the time it took was ~60 ms.
This is still tolerable.
 
Last edited:
  • +Reputation
Reactions: simmerskool
Trident said:
For inefficient operations in the registry, it makes big difference.
Click to expand...

At the shutdown, the disk can be busy depending on running applications that may need to save data. Furthermore, many people still do not use SSD.
There are many unknown factors.
 
  • +Reputation
  • Like
Reactions: simmerskool and Trident

You may also like...