View Issue Details

IDProjectCategoryView StatusLast Update
0002591Kali LinuxGeneral Bugpublic2018-01-29 13:37
Reporteradgn Assigned Tog0tmi1k  
Status closedResolutionsuspended 
Product Version2.0 
Summary0002591: openvas hang when rebuilding NVT cache

As stated in 0002250
Tried re installing openvas, removing caches, removing plugins and scripts
Still hangs.

Tried removing package and everything in /var/lib/openvas

Did a re install
re init

Still hangs

Steps To Reproduce

openvas --rebuild --progress

Attached Files
openvas-setup.diff (516 bytes)   
--- /media/root/persistence/rw/usr/bin/openvas-setup	2015-09-11 09:11:46.000000000 +0000
+++ /usr/bin/openvas-setup	2016-08-23 16:42:39.872940751 +0000
@@ -26,6 +26,7 @@
 service openvas-scanner stop 
+openvasmd --modify-scanner 08b69003-5fc2-4037-a479-93b440211c73 --scanner-port 9391 --scanner-ca-pub /var/lib/openvas/CA/cacert.pem --scanner-key-pub /var/lib/openvas/CA/servercert.pem --scanner-key-priv /var/lib/openvas/private/CA/serverkey.pem
 openvasmd --migrate
 openvasmd --progress --rebuild
openvas-setup.diff (516 bytes)   




2015-09-03 10:01

administrator   ~0003896

I can't reproduce this. For sure it takes a long time but it works.

What does openvas-check-setup report?



2015-09-04 19:47

reporter   ~0003950

openvas-check-setup works fine, says that everything is ok.

Had the NVT for a long time. 1-2 days, and it was up and running.
But the Scanning does not work now, and taking a closer look it seems to hang on the NVT's
Smells like something might be wrong with the NVT's that causes it to hang :/

Ill do a new NVT update today and see if it was a plugin error.



2015-09-18 22:29

reporter   ~0004015

with everything shutdown, I start openvas-scanner and wait for it to load all the way.

root@mexikali:~# openvassd

wait about 30 seconds...

root@mexikali:~# lsof -itcp:9391
openvassd 29698 root 4u IPv4 368130 0t0 TCP *:9391 (LISTEN)

In another window, I start a tcpdump.

root@mexikali:~# tcpdump -i any port 9391
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on any, link-type LINUX_SLL (Linux cooked), capture size 262144 bytes

In the first window, I try to rebuild.

root@mexikali:~# openvasmd --rebuild --verbose --progress
Rebuilding NVT cache... /

The spinner stops there and never resumes.

The tcpdump shows almost no data changing hands other a handshake and PSH 218 long. This hangs forever.

15:20:59.086164 IP localhost.49591 > localhost.9391: Flags [S], seq 1557381704, win 43690, options [mss 65495,sackOK,TS val 331588206 ecr 0,nop,wscale 10], length 0
15:20:59.086173 IP localhost.9391 > localhost.49591: Flags [S.], seq 244454702, ack 1557381705, win 43690, options [mss 65495,sackOK,TS val 331588206 ecr 331588206,nop,wscale 10], length 0
15:20:59.086181 IP localhost.49591 > localhost.9391: Flags [.], ack 1, win 43, options [nop,nop,TS val 331588206 ecr 331588206], length 0
15:20:59.086288 IP localhost.49591 > localhost.9391: Flags [P.], seq 1:219, ack 1, win 43, options [nop,nop,TS val 331588206 ecr 331588206], length 218
15:20:59.086293 IP localhost.9391 > localhost.49591: Flags [.], ack 219, win 44, options [nop,nop,TS val 331588206 ecr 331588206], length 0

I would expect that lsof would show an ESTABLILSHED connection from both sides at this point, but I only see one side.
In a third window, I get this.

root@mexikali:~# lsof -itcp:9390,9391
openvassd 29698 root 4u IPv4 368130 0t0 TCP *:9391 (LISTEN)
openvasmd 29701 root 7u IPv4 368697 0t0 TCP localhost:49591->localhost:9391 (ESTABLISHED)

Is there any more info I can provide?



2016-04-30 16:48

reporter   ~0005171

Confirming this bug. I am able to reproduce it each time I rebuild the NVT cache.



2016-05-24 18:28

reporter   ~0005279

not to pile on, but confirming this as well



2016-05-25 19:11

reporter   ~0005280

Getting this too. If anyone has a workaround please post. Scans are dead now.



2016-06-16 11:52

reporter   ~0005377


I dont know if this is related:

rebuild hangs for me at this point every time:

rt_sigaction(SIGCHLD, {SIG_DFL, [], SA_RESTORER, 0x7fc35af01d40}, NULL, 8) = 0
clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7fc35bfa1b50) = 8137
wait4(8137, ^Cstrace: Process 8136 detached
<detached ...>

I cannot determine why yet...



2016-06-20 10:20

reporter   ~0005396

+1 fresh install of kali and openvas packages. Worked fine for a week but now I can't run any scans.

openvasmd --rebuild --listen --progress --verbose

just hangs at Rebuilding NVT cache... /

I did get "Updating NVT cache" in the openvasmd.log when I specified listening on but other than that I'm stuck for ideas on what to do next.



2016-06-21 22:43

reporter   ~0005405

still the same with even a very fresh installation of OpenVAS!
is this could be a sign of starting to have a commercial version?!



2016-06-24 07:41

manager   ~0005409

I didn't reproduce this issue.
I update all packages for openvas 8 (libraries, scanner, manager, etc). There are changes on NVT cache update.
Please upgrade your system and let us know if you still have the problem.



2016-08-24 01:50

reporter   ~0005666

Last edited: 2016-08-24 02:04

I can confirm that this issue exists and offer a workaround/fix. The issue ONLY happens on fresh installs. (i.e. when fresh SSL keys are generated in <openvas_root>/CA/*) and appears to occur because the script tries to update the NVD cache before openvas-scanner is configured with the (newly created) TLS key...

For me the fix was to add the following line on line 29 of the file /usr/bin/openvas-setup (before running it):

openvasmd --modify-scanner 08b69003-5fc2-4037-a479-93b440211c73 --scanner-port 9391 --scanner-ca-pub /var/lib/openvas/CA/cacert.pem --scanner-key-pub /var/lib/openvas/CA/servercert.pem --scanner-key-priv /var/lib/openvas/private/CA/serverkey.pem

(See attached diff file)

This command updates the SSL keys used by the openvas-scanner after which the NVD cache update should complete. (This command can also be run manually on systems that have already been setup. After that the NVD cache should be updated manually with - 'openvasmd --update && openvasmd --rebuild'. )



2016-08-29 13:11

reporter   ~0005691

Last edited: 2016-08-29 13:41

I'm currently having this issue as well. Check-Setup advised me to delete and rebuild, but it just hangs. I just let it "rebuild" from Friday afternoon and it's not complete Monday morning. The only way I can fix this, is to totally reinstall Kali. Adding the line to Openvas-Setup per quant0 did not resolve this.

Prior to a fresh install, I also tried to start from scratch by performing the following, and it would hang while rebuilding at the initial setup like before.

apt-get purge openvas openvas-* ;
rm -fr /var/cache/openvas;
rm -fr /var/log/openvas;
rm -fr /var/lib/openvas;
apt-get autoremove;
apt-get install alien nsis rpm;
apt-get install openvas;



2016-09-09 08:05

reporter   ~0005805

I can confirm what Muhaski reports. Same here. This is what I see on the console:

\md main: DEBUG:4363:2016-09-04 11h27.55 utc: sql_open: db open, max retry sleep time is 0
/md main: DEBUG:4363:2016-09-04 11h27.55 utc: sql_open: db open, max retry sleep time is 0
\md otp-Message: Scanner loading: 49100 / 49127 nvts.

/md main: DEBUG:4393:2016-09-04 11h28.06 utc: sql_open: db open, max retry sleep time is 0
\md main: DEBUG:4393:2016-09-04 11h28.07 utc: sql_open: db open, max retry sleep time is 0



2016-09-11 18:29

reporter   ~0005824

Last edited: 2016-09-11 18:30

I had the same problem with openvas (not on kali but ubuntu).
I followed the same steps as Muhaski without success (so no difference).
But I had success (yay!) after I did this:

backup tasks.db to a safe location (mine was in /var/lib/openvas/mgr/tasks.db)

apt-get purge openvas openvas-* ;
rm -fr /var/cache/openvas;
rm -fr /var/log/openvas;
rm -fr /var/lib/openvas;
apt-get purge redis


apt-get install openvas

I think the only thing I did different the 2nd time was the purging of the redis database and the reboot. Perhaps just purging redis is enough. If it doesn't help, let me know, perhaps I forgot another step I did differently and I could check...

Oh yeah, to restore tasks.db: stop openvas, put the file back, then start it again. I then got a 503 error when I started a new scan in greenbone security assistant. I followed this guide to fix it:

Hopefully it helps someone.



2016-09-12 13:46

reporter   ~0005836

I performed the same steps as syzop, and the setup completed this time. I believe my autoremove command previously removed redis, but I never performed a reboot.



2016-09-13 07:38

reporter   ~0005842

It works. Reinstalling Redis was key.



2017-01-15 02:22

reporter   ~0006249

I had this issue on a Raspberry Pi running the Kali image.

We noticed when we attempted to run:

omp --xml='<start_task task_id="3a53b4a8-80f7-4669-ab70-0aef5fb503f7"/>'

That the task would never fire off. We checked in the browser and attempted to start a task, and create a new task, and new target, and even re-run a pre-existing task, but the task would never start.

After running:

'apt-get purge redis-server'
'apt-get purge openvas'
'apt-get install openvas'

the issue was corrected. Redis appeared to be the issue, I could tell by watching the "Rebuilding NVT Cache" hang, and quit processing, but it kept calling redis over and over every now and then, and do nothing. I checked redis logs but nothing is logged there, except for:

WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.

Server started, Redis version 3.2.6

WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.

There are some possibilities why my redis database may have become corrupted...

I am using a mSD card and the filesystem is ext4.

As this is a Pi v3, we have tested unexpected shutdown by disconnecting the power.

The error in the redis logs might indicate redis could be prone to "Background save may fail" condition because of low memory, which this Piv3 has 1 GB of memory, while OpenVas recommends 4 GB.



2017-01-15 15:37

reporter   ~0006254

Reproduced the error by simply initiating a scan on my target subnet with default settings. Openvas crashed after exceeding memory.
Found redis database corrupted, and resolved quickly using above process.
Resolved issue further and executed a scan by doing:

/etc/openvas# nano openvassd.conf



2018-01-29 13:37

administrator   ~0008301

Due to the age of the OS (Kali Moto [v1], Kali Safi [v2], Kali Rolling 2016.x), these legacy versions are no longer supported.
We will be closing this ticket due to inactivity.

Please could you see if you are able to replicate this issue with the latest version of Kali Linux -

If you are still facing the same problem, feel free to re-open the ticket. If you choose to do this, could you provide more information to the issue you are facing,and also give information about your setup?
For more information, please read:

Issue History

Date Modified Username Field Change
2015-08-24 14:02 adgn New Issue
2015-09-03 10:01 rhertzog Note Added: 0003896
2015-09-03 10:01 rhertzog Status new => feedback
2015-09-03 10:01 rhertzog Product Version kali-dev => 2.0
2015-09-04 19:47 adgn Note Added: 0003950
2015-09-04 19:47 adgn Status feedback => new
2015-09-18 22:29 pdxdoughnut Note Added: 0004015
2015-11-06 23:44 bhjr Issue cloned: 0002767
2016-04-30 16:48 petero Note Added: 0005171
2016-05-24 18:28 bucky67gto Note Added: 0005279
2016-05-25 19:11 atatistcheff Note Added: 0005280
2016-06-16 11:52 laurencesgill Note Added: 0005377
2016-06-20 10:20 philosifer Note Added: 0005396
2016-06-21 22:43 kengolive Note Added: 0005405
2016-06-24 07:41 sbrun Note Added: 0005409
2016-08-24 01:50 quant0 Note Added: 0005666
2016-08-24 01:51 quant0 File Added: openvas-setup.diff
2016-08-24 02:04 quant0 Note Edited: 0005666
2016-08-29 13:11 Muhaski Note Added: 0005691
2016-08-29 13:41 Muhaski Note Edited: 0005691
2016-09-09 08:05 petero Note Added: 0005805
2016-09-11 18:29 syzop Note Added: 0005824
2016-09-11 18:30 syzop Note Edited: 0005824
2016-09-12 13:46 Muhaski Note Added: 0005836
2016-09-13 07:38 petero Note Added: 0005842
2017-01-15 02:22 nodetx Note Added: 0006249
2017-01-15 15:37 nodetx Note Added: 0006254
2018-01-29 13:37 g0tmi1k Assigned To => g0tmi1k
2018-01-29 13:37 g0tmi1k Status new => closed
2018-01-29 13:37 g0tmi1k Resolution open => suspended
2018-01-29 13:37 g0tmi1k Note Added: 0008301