Firewall incorrectly identifies application that send ICMP echo requests [M1463]

A. THE BUG/ISSUE (Varies from issue to issue)
Can you reproduce the problem & if so how reliably?:
Yes very reliably
If you can, exact steps to reproduce. If not, exactly what you did & what happened:
1:remove all firewall application rules
2:set firewall mode to custom ruleset
3:open a windows command prompt (cmd.exe)
4:run ping e.g. google.com
5:notice a comodo firewall alert for “System” wants to connect to the internet with protocol ICMP
One or two sentences explaining what actually happened:
Any application that uses the windows api IP Helper functions to send ICMP echo requests, will be recognized as “System” instead of the actual application making the request. Because “System” is part of the “Windows System Applications” file group, and by default have the “allowed application” ruleset applied to itself in firewall application rules, any unknown application can leak data past the firewall without warning.
One or two sentences explaining what you expected to happen:
I expected the actual application (ping.exe in this case) name to appear in the firewall alert.
If a software compatibility problem have you tried the advice to make programs work with CIS?:
N/A
Any software except CIS/OS involved? If so - name, & exact version:
No
Any other information, eg your guess at the cause, how you tried to fix it etc:
N/A

B. YOUR SETUP
Exact CIS version & configuration:
CIS version 8.1.0.4426 Proactive configuration
Modules enabled & level. D+/HIPS, Autosandbox/BBlocker, Firewall, & AV:
HIPS=enable, Autosandbox=enabled, Firewall=custom ruleset, AV=not installed
Have you made any other changes to the default config? (egs here.):
remove all application rules under firewall settings set firewall mode to custom ruleset
Have you updated (without uninstall) from CIS 5, 6 or 7?:
No clean install
if so, have you tried a a a clean reinstall - if not please do?:
Yes
Have you imported a config from a previous version of CIS:
No
if so, have you tried a standard config - if not please do:
Yes Proactive config
OS version, SP, 32/64 bit, UAC setting, account type, V.Machine used:
Windows 7 SP1 x64, UAC=disabled, account type=admin, non-virtual machine
Other security/s’box software a) currently installed b) installed since OS, including initial trial security software included with system:
a=N/A b=N/A

[attachment deleted by admin]

have you tried testing the latest beta to see if this bug is still present?

https://forums.comodo.com/beta-corner-cis/comodo-internet-security-8204474-beta-released-t110199.0.html

Is this the same bug thats already in the tracker?
https://forums.comodo.com/format-verified-issue-reports-beta-corner-cis/icmp-not-configured-m1462-t110327.0.html

This bug has been present since the release of version 6, I just didn’t bother reporting it thinking it would be fixed with newer releases. Yes it still is present in the beta and no its not related to the other bug in the tracker.
edit: seen the report, it is somewhat related, see my reply in that bug report.

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 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.

Still a bug with version 8.2.0.4508. However this may not be easily fixed as I think its an issue with the windows filtering platform that is now being incorporated with CIS since V6 as explained in this post for a bug with jumbo frames.

Bug report for jumbo frames.

I’ve updated tracker data: linked reports, marked as ‘not fixed’.

Thanks.

@futuretech, please attach your configuration and a video in order to further investigate this issue.

Thank you.

A video with the latest release - YouTube and one I did with the BETA - YouTube

[attachment deleted by admin]

Linked in the tracker.

Thank you.

PS: Corrected your post.

We’ve been informed that there is no value in fixing with the following explanation,

When you ping any host from your zone, workflow of network packet is :
Application (‘ping.exe’) → TCP/IP protocol → Network Adapter → Remote Host.
‘ping.exe’ uses ICMP’s native socket, which is owned by the system, so this kind of packet belongs to system process.

When your local machine received inbound ICMP packet, workflow of network packet is:
Remote Host → Network Adapter → TCP/IP protocol.

  1. If the connection is launched from local machine (eg you ping any host from local machine and get response from related host), the packet belongs to system process.
  2. If the connection is launched from remote machine (eg you ping local machine from other host firstly), TCP/IP protocol will reply the packet, and no application will deal with inbound packet. Thus, default inbound ICMP is from “Windows Operation System".

I will move this report to “Resolved”. Feel free to contest the decision if you find out something that is incorrect.
Thank you.

Ignore by previous reply. Fixed with upcoming stable version 10.

Hope it helps.