Blocked Intrusions: Access Memory: procexp.exe, cistray.exe

I see thousands of Blocked Intrusions for Process Explorer trying to access memory of Comodo.
I trust both of them and I don’t want Comodo to handle it as an intrusion.
How to do so?

What you are seeing is the self-protection of CIS, it’s protecting its own memory from other applications.

I would recommend not changing these settings however I will still show you how.

  • Open the main CIS GUI.
  • Click Tasks in the upper-right corner.
  • Expand Advanced Tasks
  • Click Open Advanced Settings
  • Expand Security Settings in the left menu of the new window.
  • Expand Defense+
  • Expand HIPS
  • Click HIPS Rules
  • Scroll down among the rules til you get to the bottom, you should see a rule for the File Group COMODO Internet Security
  • Right-click the HIPS rule for COMODO Internet Security and click Edit
  • A new window should have opened, in it there should be two tabs Access Rights and Protection Settings, click Protection Settings
  • Locate Interprocess Memory Accesses and click Modify (X) to the right of it.
  • A new window should appear, right-click in the list and click Add > Files and then locate the file you want to exclude (procexp.exe) and then highlight the executable and click Open
  • Click OK on all remaining windows.

This stuff can get tricky. And it really depends upon the integrity of the process doing the access, the critical nature of the process being accessed, the risk either could become compromised and the consequences of rogue applications. High risk / low consequence vs low risk / high consequence.

From the resource access paradigm implemented by CIS HIPS, i.e., D+, the first step is how is any arbitrary application launched. As it is, Process Explorer is a SysInternals utility and on its face can be considered ‘trusted’. It would, in my mind, be one of those things - akin to regedit, e.g., - I do not allow to run without explicit permission by myself.

Once an app is executing, it needs resource access rights. One of the resource access names that permissions can be granted for is ‘inter-process memory access’ It is completely expected that Process Explorer would want to access any component of CIS that is executing at the time Process Explorer is running. It will alert its desire to do so. Given that its a ‘trusted’ system application, access rights for the resource access name ‘inter-process memory access’ can be granted to procexp.exe for whatever CIS component it desires.

However, what should be also implemented is that any CIS component should have its ‘protection settings’ enabled - in order for monitoring of action occurring against said image to be enabled - otherwise the image will be mute about such. ‘Protection Settings’ establishes protection against action by another image to it.

An example of this is ‘Windows System Applications’ file-group which has ‘Windows System Application’ default predefined policy. That policy allows any and all inter-process memory access, Windows System Applications are about as trusted as things can get, no? However, Comodo Internet Security file-group has the ‘Protection Settigs’ enabled for ‘Windows System Applications’ in addition to explicitly permissions granted to %PROGRAMFILES%\Comodo\COMODO Internet Security*

What that last ‘Protection Setting’ allows is any CIS component whatsoever, is allowed inter-process memory access to those components implicit in the Comodo Internet Security file-group.

What I’m unclear on is how the logs will reflect the latter occurring, i.e., an images memory is being accessed by another process. It may depend upon the quality of inter-process memory access, i.e., not all access are congruent; viewing memory is not the same as altering memory contents. So the target of inter-process memory access may not complain unless its memory allocations are being disturbed.

The source image can be blocked from accessing any arbitrary application memory allocation, i.e., Process Explorer can be blocked inter-process memory access to Comodo Internet Security. Then it doesn’t matter what ‘Protection Settings’ CIS has; it will never see the access attempt. However, Process Explorer may require such access, and if granted such may open the door to allow such access by CIS itself.

That’s quite a mouthful to get one’s brain around. :o

Process Explorer does not need memory access to CIS. It is sloppy programming of programs when they will keep on hammering for memory access when it is not given.

Allowing memory access will weaken the self defense of CIS in case Process Explorer would get exploited by a malware.

I would say if it ain’t broken don’t fix it.

Well, if what say is indeed true, then Process Explorer request for inter-process memory access rights to CIS images should be blocked. Otherwise, all that Protection Settings avails - if resource access names actually are being monitored - is the exclusion, i.e., to allow. Seems as if the default Protection Settings is inactive, and the conventional paradigm is block at the source.

I took a look in my rules, and found that I’ve configured ProcMon - a similar SysInternals app - and found the only resource access permissions for the inter-process memory access name was an exclusion for SYSTEM, i.e., a component of Windows System Applications. That file-group comprises several other executable images. My configuration for Windows System Applications implements the predefined policy of Windows System Application. The Windows System Application predefined policy had all Protection Settings Protection Settins access names set inactive. I’ve now activated all Protection Settings for Windows System Application.

I’ve also activated all Protection Settings for Comodo Internet Security file-group. Would allowing Windows System Applications to have inter-process memory access of Comodo Internet Security file-group components be a problem?


This has piqued my interest now to go through all D+ rules and check which system critical components have rules with Protection Settings inactive.