Process detection bug

If you use PsSetCreateProcessNotifyRoutine or PsSetCreateProcessNotifyRoutineEx then it’s system to blame otherwise you’re bad in things like proactive detection or running processes
Here’s the example of the same ghost processes like they were in Active Process list.

I don’t know where do you read the process file path but after some time and obvious manipulation like renaming as seen, CIS fails to detect processes well and thus disregards rules, dig.signatures and etc. Broken process detection code.

FYI better use PsSetCreateProcessNotifyRoutine / PsSetCreateProcessNotifyRoutineEx or parse IRPs rather than some bad handmade untrusted methods.

And below happened all the time FF process was started. System reboot helped this weird situation. This is hardly reproducible bug appearing time to time. Look into depth of your process detection routines.

[attachment deleted by admin]

A. THE BUG/ISSUE: Executable code and processes can disappear from comodos detection system, thereby bypassing all set rules

  1. What you did: As an example, run the executable firefox.exe
  2. What actually happened or you actually saw: Process executes and shows up in windows taskmanager but comodo can not see the executable code at all, not even in comodos active task list.
  3. What you expected to happen or see: I expect the executable code to be detected, identified, and have appropriate rules applied to its role.
  4. How you tried to fix it & what happened: Nothing I can do to prevent this bug from occuring. Rebooting the PC and performing the exact same steps sometimes functions correctly, but most of the time it does not.
  5. If a software compatibility problem have you tried the compatibility fixes (link in format)?: I am running the latest version of CIS and all major security patches to Windows 7 have been applied.
  6. Details & exact version of any software (execpt CIS) involved (with download link unless malware): For the sake of this example, Firefox Aurora 12.0a2 (2012-02-08)
  7. Whether you can make the problem happen again, and if so precise steps to make it happen: Yes, the problem does not occur consistently though. To reproduce the problem place firefox in ‘Always Sandbox’, then just reboot the PC, log into the user account and run the executable firefox.exe, there is about a 50% chance that comodo will not detect firefox.exe and I will be forced to reboot again until it is detected upon execution by comodo.
  8. Any other information (eg your guess regarding the cause, with reasons): I think there is some kind of timing issue regarding your process watch function in the core code block. It is possible that your compiler is causing a race condition by multi-threading it, and it may have something to do with the core code for the executable process detection not being specifically designed for multicore operations, but regardless is being compiled as if it were.

B. FILES APPENDED. (Please zip unless screenshots).:

  1. Screenshots of the Defense plus Active Processes List (Required for all issues): Yes
  2. Screenshots illustrating the bug: Yes
  3. Screenshots of related CIS event logs:
  4. A CIS config report or file:
  5. Crash or freeze dump file:
  6. Screenshot of More~About page. Can be used instead of typed product and AV database version:


  1. CIS version, AV database version & configuration: CIS - 5.9.221665.2197 , Virus Sig DB - 11491
  2. a) Have you updated (without uninstall) from a previous version of CIS: No
    b) if so, have you tried a clean reinstall (without losing settings - if not please do)?:
  3. a) Have you imported a config from a previous version of CIS: No
    b) if so, have U tried a standard config (without losing settings - if not please do)?:
  4. Have you made any other major changes to the default config? (eg ticked ‘block all unknown requests’, other egs here.): No
  5. Defense+, Sandbox, Firewall & AV security levels: Def = Safe, Sandbox = Enabled, Firewall = Custom, AV = Stateful.
  6. OS version, service pack, number of bits, UAC setting, & account type: Windows 7 SP1 64bit , UAC enabled, standard user account
  7. Other security and utility software currently installed: None
  8. Other security software previously installed at any time since Windows was last installed: None, this was installed onto a fresh install on Win7
  9. Virtual machine used (Please do NOT use Virtual box)[color=blue]: None

[attachment deleted by admin]

Thank you very much for your report in standard format, with all information supplied. The care you have taken is much appreciated by Comodo, and will increase the likelihood that this bug can be fixed.

Developers may or may or may not communicate with you in the forum or by PM/IM, depending on time availability and need. Because you have supplied complete information they may be able to replicate and fix the bug without doing so.

Many thanks again

Two questions:

  1. Do you have enhanced protection mode ticked under D+ settings. You should do on a 64 bit machine, else bypass is possible.
  2. Are you continually downlodng new build of firefox? I suspect that ‘Always sandbox’ may identify files by hash, if so it would cause CIS to ignore the sandox role for a new build. (That doesn’t explain all of your symtoms though).

Best wishes


This issue appears to me to be the same as one already on file. Accordingly, I will merge them, if that’s OK. You can locate the merged report by follwing the link in the email notification.

If you don’t agree please PM any active mod with your reasons and, if appropriate, they will unmerge the issue.

Many thanks

This is no sandbox related!
In the 1s case no sandbox used. Just D+ and some Explorer dir manipulations on renaming, etc.

Admin, don’t try fix that’s pretty self-explained. Remove sandbox from title and put prev naming on general process detection not sandbox related.

And finally - the cause can be that some processes run as Jobs in WOW or file system redirection…

Here is all of my CIS XML configuration settings in a zip file.
Along with some screenshots of my D+ settings.
As far as I can tell from the XML settings file, there is no hash being stored on the firefox exe in the sandbox settings.

Sometimes, when I do update the file manually it will detect it as a new file and ask how I want to treat it, I will select web browser and save the setting. I then go into the settings and clean out any old instances or duplicate firefox rules from the old exe file.

[attachment deleted by admin]

This is a complete bug as firefox and its files have been digitally signed and signature releaser is in whitelist.
I see a logic bug in precedence of analysis or this is a feature that prohibits the unknown in cloud digitally signed objects? Disregarding whitelisted releaser and validity of dig.sig.
The question is open and is added to the methods of process recognition.

Another prediction that upon some renaming just before it the app was terminated and CIS unable to detect immediate IRP processing with rename operations on FS and/or somehow mixes names of terminated or pending processes.

Logic is the key. If it’s wrong the bugs like those 2 above can occur.

Was this run from a removable drive?
CIS handles removable drives differently this might have something to do with it.

Just to check, is the consensus that these two bugs should be split again, or is there a strong enough relation that they should stay together (eg do they seem to reasonably clearly be two manifestations of one underlying cause?).

Best wishes


OK, no removable drives. And no, CIS handles them in the same way as they appear as “volumes” etc in object directory the same drivers, FS, etc. involved. Or you thing eSATA handled different way? No way.

The issues are the same as the CIS sandboxing is made programmatically not in h/w or o/s. Reasons are the same.
Causes can be equal - either wrong process detection or jobs(! as stated that it used for FS redirection by OS) detection.

Ok will keep together pending further analysis


I was just asking, not doubting your report.

There are two conditions which cause my particular bug to show up 100% of the time.

  1. If I run a program like k10stat.exe from a user account and it requires UAC and administrator credentials as you can see in the process list.

  2. If the PC goes into sleep mode and is awakened, the firefox process will never be recognized in the comodo task list.

And to answer the conjecture above regarding the renaming of the executable code right before execution. You are correct in that assumption, as I have witnessed firefox.exe turns into FIREFOX.EXE right after it is run. The executable executes itself and in-line compiles part of it’s own program code and re-executes itself.

If this is an issue where the maker is digitally signed and trusted automatically then it should be discussed as a possible exploitation point. As the browser itself is capable of compilation and execution of malicious code. The browser itself is not suspect but the code it compiles and renders is. Just recently there was a reward from Mozilla issued for someone revealing a simple bug that allowed a remote attacker complete control of a remote PC by using escape codes as a chrome window name.

This problem is still relevant and there has been no updates yet.