Building openvas-scanner from latest source, scan is hanged

Hi all,

I tried to build openvas-scanner from source code in Github and noticed that scan is hanged and missing findings starting from this commit: https://github.com/greenbone/openvas-scanner/commit/9925edca36f30d3b17ce4d15596cc858bd4e23f8, building with the previous commits is fine.

Please raise a new issue in the issue tracker below as otherwise the chances are high that this doesn’t get noticed.

https://github.com/greenbone/openvas-scanner/issues

Edit: I have pinged the responsible team internally but there is no guarantee that this will get picked up so it is still recommended to raise an issue in the issue tracker above

Hi @panajo1017,
thanks for reporting this. I think I found the issue and should be fixed with https://github.com/greenbone/openvas-scanner/pull/1240 .

2 Likes

Hi @jjnicola,

I tried to build with the merged code, but scans are still hanged.

I forgot to mention, the scan is usually hanged at a specific percent of progress (70% - 100%), the log files don’t show any exception, signature check is disabled.

Here is the log of a Host Discovery scan:

sd   main:MESSAGE:2022-11-29 03h13.24 utc:12034: openvas 22.4.1~dev1 started
sd   main:MESSAGE:2022-11-29 03h13.24 utc:12034: attack_network_init: INIT MQTT: SUCCESS
sd   main:MESSAGE:2022-11-29 03h13.24 utc:12034: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started: Target has 4 hosts: A, B, C, D, with max_hosts = 20 and max_checks = 4
libgvm boreas:MESSAGE:2022-11-29 03h13.24 utc:12034: Alive scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started: Target has 4 hosts
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12047: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started for host: A
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12049: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started for host: C
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12048: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started for host: B
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12049: Running LSC via Notus for C
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12047: Running LSC via Notus for A
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12047: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f finished for host A in 0.15 seconds
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12048: Running LSC via Notus for B
sd   main:MESSAGE:2022-11-29 03h13.25 utc:12049: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f finished for host C in 0.27 seconds
libgvm boreas:MESSAGE:2022-11-29 03h13.27 utc:12034: Alive scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f finished in 3 seconds: 4 alive hosts of 4.
sd   main:MESSAGE:2022-11-29 03h13.27 utc:12050: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f started for host: D
sd   main:MESSAGE:2022-11-29 03h13.27 utc:12048: Vulnerability scan 5afb9c32-dab5-488d-851c-3d8db7bcaa3f finished for host B in 2.76 seconds

Hanged here (75%)

Another note: Scans sometimes finish normally (same target and configs). Scans that are hanged also finish after a long time, but missing findings.

HI @panajo1017, I think I mixed the issues. The PR mentioned above was a fix for another issue.
I was able to reproduce the scanner hangs.
I added a commit to fix this issue into a new PR, which should be merged in stable until the end of the day.
Thanks again for reporting and giving feedback.
Best regards.
https://github.com/greenbone/openvas-scanner/pull/1216

4 Likes

I built the scanner with the latest stable source and confirmed that the issue was fixed.
Happy that the issues are fixed quickly.

3 Likes

Hi all,

After scanning more targets, I noticed that some tasks are still hanged. I’m not sure if this has the same root cause with the above issue.

I set log_whole_attack = yes for openvas, the log file indicated that the scanner is still running against the target, but got timeout for each VT. If I stop the task manually, the task status is set to Stopped, but the scanner kept running.

Following is some log lines in openvas.log:

sd   main:MESSAGE:2022-12-04 20h29.55 utc:18381: Launching 2014/gb_clipperz_password_manager_rce_vuln.nasl (1.3.6.1.4.1.25623.1.0.804607) against IP [27120]
sd   main:MESSAGE:2022-12-04 20h35.15 utc:18381: 1.3.6.1.4.1.25623.1.0.200004 (pid 26705) is slow to finish - killing it
...
sd   main:MESSAGE:2022-12-04 20h45.55 utc:18381: Not launching 2010/gb_cruxpa_xss_vuln.nasl (1.3.6.1.4.1.25623.1.0.801383) against IP because a mandatory key is missing (
this is not an error)
sd   main:MESSAGE:2022-12-04 20h45.55 utc:18381: Launching 2012/gb_ctek_skyrouter_50867.nasl (1.3.6.1.4.1.25623.1.0.103479) against IP [28670]
sd   main:MESSAGE:2022-12-04 20h49.08 utc:18355: Stopping host IP scan (pid: 18381)
sd   main:MESSAGE:2022-12-04 20h49.09 utc:18355: Vulnerability scan 97de724b-22ba-4579-88a9-96d3708094bb finished in 13685 seconds: 1 alive hosts of 1
lib  misc:MESSAGE:2022-12-04 20h49.15 utc:28827: open_sock_tcp: IP:2087 time-out.
lib  misc:WARNING:2022-12-04 20h49.15 utc:28827: check_kb_inconsistency_log: No internal/scanid found; abort to prevent data corruption.
lib  misc:MESSAGE:2022-12-04 20h49.15 utc:28974: open_sock_tcp: IP:2082 time-out.
lib  misc:MESSAGE:2022-12-04 20h49.15 utc:28975: open_sock_tcp: IP:2082 time-out.
lib  misc:WARNING:2022-12-04 20h49.15 utc:28975: check_kb_inconsistency_log: No internal/scanid found; abort to prevent data corruption.
lib  misc:WARNING:2022-12-04 20h49.15 utc:28974: check_kb_inconsistency_log: No internal/scanid found; abort to prevent data corruption.

Hi @panajo1017 ,
There is a Pull Request pending for review. This should fix the issue with stop scans. And again, Thanks a lot for your feedback.
https://github.com/greenbone/openvas-scanner/pull/1252

3 Likes

I confirmed that the issue with stop scans was fixed, but some scans still seem to be hanged as there are no new reports in several hours after a period of scan time. Currently no abnormal message in the logs. I will report later if I find something new.

1 Like

Following is the log of a task that is hanged:

lib  misc:MESSAGE:2022-12-19 00h04.51 utc:17933: open_sock_tcp: host1 time-out.
lib  misc:MESSAGE:2022-12-19 00h05.31 utc:17933: open_sock_tcp: host1 time-out.
lib  misc:MESSAGE:2022-12-19 00h08.12 utc:18365: open_sock_tcp: host2 time-out.
lib  misc:MESSAGE:2022-12-19 00h08.52 utc:18365: open_sock_tcp: host2 time-out.
sd   main:MESSAGE:2022-12-19 00h15.03 utc:5972: Running LSC via Notus for host3
sd   main:MESSAGE:2022-12-19 00h15.04 utc:5972: Vulnerability scan 481caaa3-25c5-466e-b6ad-0b27c6e2dcbd finished for host host3 in 18851.00 seconds
lib  misc:MESSAGE:2022-12-19 00h34.27 utc:21264: open_sock_tcp: host4:5986 time-out.
lib  misc:MESSAGE:2022-12-19 00h35.07 utc:21264: open_sock_tcp: host4:5985 time-out.

Scan hanged here, manually stop task

sd   main:MESSAGE:2022-12-19 03h15.22 utc:5936: Stopping host host4 scan (pid: 5955)
sd   main:MESSAGE:2022-12-19 03h15.24 utc:5936: Vulnerability scan 481caaa3-25c5-466e-b6ad-0b27c6e2dcbd finished in 29680 seconds: 5 alive hosts of 254

The scan have not finished for host1, host2, host4 in hours, there are no scan results updated also.
This behavior is quite similar to the issues before (fixed in https://github.com/greenbone/openvas-scanner/pull/1216), but happened less often.

When I stop the task manually, the log showed that the scanner only stop scan the host4 but not host1, host2.

Hi all,

It’s been a long time, but the error still happened. I’m using the latest scanner built from the stable source, some scans that have many hosts are stuck at about 98-99%. I think the root cause is still related to the IPC mechanism or the change in the way scanner stores results into redis, because the error started occurring when these changes were implemented to the scanner.

1 Like