Boreas use of ICMP Echo with 0 ID can cause issues on some networks

[co60ca]

Expected behavior

ICMP Echos from Boreas should use non zero id and seq. aka "Identifier" and "Sequence Number" from RFC 792 ICMP Echo. And see targets as alive.

Boreas uses identifier=0 seq=0 for ipv4 ICMP Echo requests during alive checks. Some environments appear to not like this. Despite being allowed by the spec, I think this behaviour is possibly at the least confusing since most ping tools increment the seq by one per message starting from 1, and have identifier > 0

Ipv6 echos appear to use 234 as the identifier.

This causes some environments to have all alive test fail. We are moving to "Consider Alive" however we think it benefits others to report this issue.

ping (on Ubuntu) appears to pick seq 1..n and identifier=some number above 0 thats from the kernel I believe.

When trying to debug this problem someone may attempt to use ping and because it uses a non 0 identifier and seq it will be difficult to debug when compared to the behaviour exhibited by boreas.

Actual behavior

The ICMP Echo for alive test uses identifier=0 seq=0.

Steps to reproduce

Start a scan which uses the default alive check of ICMP Echo.
Use tcpdump on the target. As such tcpdump -v icmp and (src 192.168.1.1 or dst 192.168.1.1) &

You will see

SENT (1.0342s) ICMP [192.168.1.30 > 192.168.1.1 Echo request (type=8/code=0) id=0 seq=0] IP [ttl=64 id=25987 iplen=28 ]
You will not receive a response if the environment does not appear to allow identifier = 0 Echos.

GVM versions

I recognize these are older but given the code appears to be unchanged in the last 3-4 years I think the problem still exists.

gsa: (gsad --version)
We do not use gsa

gvm: (gvmd --version)
Greenbone Vulnerability Manager 21.4.5~git-f27009b24-HEAD

openvas: (openvas --version)
OpenVAS 21.4.0~git-32ad87a4-HEAD

gvm-libs:
gvm-libs 21.4.4~git-59c8402c-HEAD

Environment

Operating system:

uname -a
Linux <HOSTNAME> 5.4.0-148-generic #165-Ubuntu SMP Tue Apr 18 08:53:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

cat /etc/lsb-release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.6 LTS"

Installation method / source: (packages, source installation)

We run a mostly unmodified source install.

Logfiles

libgvm boreas:  DEBUG:2024-04-12 22h38.28 utc:1055519: alive_detection_init: Initialise alive scanner.
libgvm boreas:  DEBUG:2024-04-12 22h38.28 utc:1055519: alive_detection_init: Initialisation of alive scanner finished.
libgvm boreas:MESSAGE:2024-04-12 22h38.28 utc:1055519: Alive scan 07f6713f-3b46-4edb-b282-948aecfb4079 started: Target has 1 hosts
libgvm boreas:  DEBUG:2024-04-12 22h38.30 utc:1055519: scan: all ping packets have been sent, wait a bit for rest of replies.
libgvm boreas:  DEBUG:2024-04-12 22h38.31 utc:1055519: stop_sniffer_thread: Try to stop thread which is sniffing for alive hosts.
libgvm boreas:  DEBUG:2024-04-12 22h38.33 utc:1055519: stop_sniffer_thread: pthread_join() returned PTHREAD_CANCELED.
libgvm boreas:  DEBUG:2024-04-12 22h38.33 utc:1055519: stop_sniffer_thread: Stopped thread which was sniffing for alive hosts.
libgvm boreas:MESSAGE:2024-04-12 22h38.33 utc:1055519: Alive scan 07f6713f-3b46-4edb-b282-948aecfb4079 finished in 5 seconds: 0 alive hosts of 1.
libgvm boreas:  DEBUG:2024-04-12 22h38.34 utc:1055519: get_host_from_queue: Boreas already finished scanning and we reached the end of the Queue of alive hosts.

[ArnoStiefvater]

Hey @co60ca,

Thanks a lot for reporting the issue and the great report!

If the change is easy to implement we will do it soon.