Gvmd stuck at 100% with no CVE's and CPE's

bvanh · March 26, 2020, 1:29pm

GVM versions

gsa: Greenbone Security Assistant 9.0
gvm: Greenbone Vulnerability Manager 9.0.0 / Manager DB revision 221
openvas-scanner: OpenVAS 7.0.0
gvm-libs: 11.0.0

Environment

Operating system: Ubuntu
Kernel: 4.15.0-91-generic x86_64
Installation method / source: instructions from https://sadsloth.net/post/install-gvm11-src_part1/, github source tar files.

I have a fresh install, all components are up and running. I can successfully do scans.

When at rest, just freshly booted the gvmd is stuck at 100% CPU, even after loading the NVT’s ext. The only thing i’ve discovered which is off is that there are not CVE’s and CPE’s in GSA.

The feeds download fine, and gvmd imports them with no errors or warnings.

What i’ve done to try to solve this:

Flush redis cache and db
Re-Created postgresql DB
Dropped the scap-data, cert-data and plugins folder

I’m totally lost, could it be something in the feed? What else?

Kind Regards,
Bastiaan

tatooin · March 26, 2020, 1:48pm

It’s not clear. You said there is no CVE / CPE (SCAP feed not updated ?) but at the same time you said gvm import them without problems.

First time you run gvmd it needs to create the database, which takes some times, hence the 100% CPU. Perhaps you just need to wait.

Before doing anything, make sure the three feeds are properly downloaded and installed, via the “Feeds status” in GSA.

bvanh · March 26, 2020, 3:01pm

Ok, perhaps I need to clarify it a bit more.

Under non-priveledged user, I run:

greenbone-nvt-sync
greenbone-scapdata-sync
greenbone-certdata-sync

These complete with success, and drop their data into the correct folders.

Then I start ospd-openvas' and gvmd`. Now it’s expected the CPU goes to 100% because al VT’s are being processed. When this is done, accoring to the log, the CPU should dive down. This doesn’t happen, even after several hours.

This is the gvmd log:

md   main:MESSAGE:2020-03-26 14h45.59 utc:3197:    Greenbone Vulnerability Manager version 9.0.0 (DB revision 221)
md manage:WARNING:2020-03-26 14h45.59 utc:3206: database must be initialised from scanner
md manage:MESSAGE:2020-03-26 14h45.59 utc:3206: No SCAP database found
md manage:MESSAGE:2020-03-26 14h45.59 utc:3206: No CERT database found
util gpgme:MESSAGE:2020-03-26 14h46.00 utc:3206: Setting GnuPG dir to '/opt/gvm/var/lib/gvm/gvmd/gnupg'
util gpgme:MESSAGE:2020-03-26 14h46.00 utc:3206: Using OpenPGP engine version '2.2.4'
md manage:   INFO:2020-03-26 14h46.00 utc:3235: sync_scap: Initializing SCAP database
md manage:   INFO:2020-03-26 14h46.00 utc:3237: Initializing CERT database
md manage:   INFO:2020-03-26 14h46.00 utc:3237: sync_cert: Updating data from feed
md manage:   INFO:2020-03-26 14h46.00 utc:3237: update_dfn_xml: dfn-cert-2017.xml
md manage:   INFO:2020-03-26 14h46.00 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2017.xml
md manage:   INFO:2020-03-26 14h46.00 utc:3235: sync_scap: Updating data from feed
md manage:   INFO:2020-03-26 14h46.00 utc:3235: Updating CPEs
md manage:   INFO:2020-03-26 14h46.03 utc:3237: update_dfn_xml: dfn-cert-2011.xml
md manage:   INFO:2020-03-26 14h46.03 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2011.xml
md manage:   INFO:2020-03-26 14h46.05 utc:3237: update_dfn_xml: dfn-cert-2013.xml
md manage:   INFO:2020-03-26 14h46.05 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2013.xml
md manage:   INFO:2020-03-26 14h46.09 utc:3237: update_dfn_xml: dfn-cert-2015.xml
md manage:   INFO:2020-03-26 14h46.09 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2015.xml
md manage:   INFO:2020-03-26 14h46.14 utc:3237: update_dfn_xml: dfn-cert-2018.xml
md manage:   INFO:2020-03-26 14h46.14 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2018.xml
md manage:   INFO:2020-03-26 14h46.20 utc:3237: update_dfn_xml: dfn-cert-2014.xml
md manage:   INFO:2020-03-26 14h46.20 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2014.xml
md manage:   INFO:2020-03-26 14h46.23 utc:3237: update_dfn_xml: dfn-cert-2019.xml
md manage:   INFO:2020-03-26 14h46.23 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2019.xml
md manage:   INFO:2020-03-26 14h46.30 utc:3237: update_dfn_xml: dfn-cert-2008.xml
md manage:   INFO:2020-03-26 14h46.30 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2008.xml
md manage:   INFO:2020-03-26 14h46.30 utc:3237: update_dfn_xml: dfn-cert-2009.xml
md manage:   INFO:2020-03-26 14h46.30 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2009.xml
md manage:   INFO:2020-03-26 14h46.32 utc:3237: update_dfn_xml: dfn-cert-2016.xml
md manage:   INFO:2020-03-26 14h46.32 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2016.xml
md manage:   INFO:2020-03-26 14h46.37 utc:3237: update_dfn_xml: dfn-cert-2020.xml
md manage:   INFO:2020-03-26 14h46.37 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2020.xml
md manage:   INFO:2020-03-26 14h46.39 utc:3237: update_dfn_xml: dfn-cert-2010.xml
md manage:   INFO:2020-03-26 14h46.39 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2010.xml
md manage:   INFO:2020-03-26 14h46.42 utc:3237: update_dfn_xml: dfn-cert-2012.xml
md manage:   INFO:2020-03-26 14h46.42 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/dfn-cert-2012.xml
md manage:   INFO:2020-03-26 14h46.46 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K18.xml
md manage:   INFO:2020-03-26 14h46.49 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K19.xml
md manage:   INFO:2020-03-26 14h46.52 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K17.xml
md manage:   INFO:2020-03-26 14h46.58 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K16.xml
md manage:   INFO:2020-03-26 14h47.03 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K20.xml
md manage:   INFO:2020-03-26 14h47.04 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K15.xml
md manage:   INFO:2020-03-26 14h47.10 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K14.xml
md manage:   INFO:2020-03-26 14h47.13 utc:3237: Updating /opt/gvm/var/lib/gvm/cert-data/CB-K13.xml
md manage:   INFO:2020-03-26 14h47.14 utc:3237: Updating Max CVSS for DFN-CERT
md manage:   INFO:2020-03-26 14h47.16 utc:3237: Updating DFN-CERT CVSS max succeeded.
md manage:   INFO:2020-03-26 14h47.16 utc:3237: Updating Max CVSS for CERT-Bund
md manage:   INFO:2020-03-26 14h47.17 utc:3237: Updating CERT-Bund CVSS max succeeded.
md manage:   INFO:2020-03-26 14h47.17 utc:3237: sync_cert: Updating CERT info succeeded.
md manage:   INFO:2020-03-26 14h49.18 utc:3404: OSP service has newer VT status (version 0) than in database (version (null), 0 VTs). Starting update ...
md manage:   INFO:2020-03-26 14h49.28 utc:3404: Updating VTs in database ... 0 new VTs, 0 changed VTs
md manage:   INFO:2020-03-26 14h49.38 utc:3404: Updating VTs in database ... done (0 VTs).
md manage:   INFO:2020-03-26 14h50.28 utc:3479: OSP service has newer VT status (version 202003261047) than in database (version 0, 0 VTs). Starting update ...
md manage:   INFO:2020-03-26 14h53.28 utc:3479: Updating VTs in database ... 58470 new VTs, 0 changed VTs
md manage:   INFO:2020-03-26 14h53.38 utc:3479: Updating VTs in database ... done (58470 VTs).

In gsa, the feed status of all three is Current. Folowing the CVE’s of CPE’s link gives CVEs 0 of 0 and CPEs 0 of 0. While others like NVT’s hava data in gsa.

Therefore my big assumption is that the 100% gvmd stuck has something to do with the CVE/CPE import during startup of gvmd.

Hope this make’s the issue more clear.

Edit: Everything from the SCAP feed is missing in GSA.

tatooin · March 26, 2020, 3:03pm

How are you running ospd-openvas / gvmd ? What options ? Please share your systemd files.

bvanh · March 26, 2020, 3:11pm

ospd-openvas

[Unit]
Description=Job that runs the ospd-openvas daemon
Documentation=man:gvm
After=postgresql.service

[Service]
Environment=PATH=/opt/gvm/bin/ospd-scanner/bin:/opt/gvm/bin:/opt/gvm/sbin:/opt/gvm/.local/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
Type=simple
User=gvm
Group=gvm
WorkingDirectory=/opt/gvm
PIDFile=/opt/gvm/var/run/ospd-openvas.pid
ExecStart=/opt/gvm/bin/ospd-scanner/bin/python /opt/gvm/bin/ospd-scanner/bin/ospd-openvas --pid-file /opt/gvm/var/run/ospd-openvas.pid --unix-socket=/opt/gvm/var/run/ospd.sock --log-file /opt/gvm/var/log/gvm/ospd-scanner.log
Restart=on-failure
RestartSec=2min
KillMode=process
KillSignal=SIGINT
GuessMainPID=no
PrivateTmp=true

[Install]
WantedBy=multi-user.target

gvmd

[Unit]
Description=Job that runs the gvm daemon
Documentation=man:gvm
After=postgresql.service

[Service]
Type=forking
User=gvm
Group=gvm
PIDFile=/opt/gvm/var/run/gvmd.pid
WorkingDirectory=/opt/gvm
ExecStart=/opt/gvm/sbin/gvmd  --osp-vt-update=/opt/gvm/var/run/ospd.sock
Restart=on-failure
RestartSec=2min
KillMode=process
KillSignal=SIGINT
GuessMainPID=no
PrivateTmp=true

[Install]
WantedBy=multi-user.target

cfi · March 26, 2020, 4:52pm

Have you tried to install the releases from the branches like “gvmd-9.0” and install the xml_split now recommended for the upcoming releases?

github.com

greenbone/gvmd/blob/gvmd-9.0/INSTALL.md#prerequisites-for-greenbone-vulnerability-manager

# INSTALLATION INSTRUCTIONS FOR GREENBONE VULNERABILITY MANAGER

Please note: The reference system used by most of the developers is Debian
GNU/Linux 'Stretch' 9. The build might fail on any other system. Also, it is
necessary to install dependent development packages.

IMPORTANT NOTICE: This version changes quite a number of locations
and names compared to the previous version. It is highly recommended to
consider the section "Migrating to Version 8.0", unless you do not have
an old setup on your system.


## Prerequisites for Greenbone Vulnerability Manager

Prerequisites:
* cmake >= 3.0
* glib-2.0 >= 2.42
* gnutls >= 3.2.15
* libgvm_base, libgvm_util, libgvm_osp, libgvm_gmp >= 11.0.0
* PostgreSQL database >= 9.6

This file has been truncated. show original

bvanh · March 26, 2020, 7:52pm

Have now used the branches:

git clone -b gvm-libs-11.0 https://github.com/greenbone/gvm-libs.git
git clone -b gvmd-9.0 https://github.com/greenbone/gvmd.git
git clone -b gsa-9.0 https://github.com/greenbone/gsa.git
git clone https://github.com/greenbone/openvas-smb.git
git clone -b openvas-7.0 https://github.com/greenbone/openvas.git
git clone -b ospd-2.0 https://github.com/greenbone/ospd.git
git clone -b ospd-openvas-1.0 https://github.com/greenbone/ospd-openvas.git

Built everything with xml_split. When gsad is started, i see this process going high for a few minutes and then all CPU goes low. So the gvmd locked at 100% CPU seems to be fixed.

The result of the feeds is also changed, the CVE’s and CPE’s are now listed but now the NVT status is Current, but no NVT’s in the list.

The gvmd log gives repediately:

lib  osp:WARNING:2020-03-26 19h50.06 utc:5861: osp_get_vts_version: element VTS missing.
md manage:WARNING:2020-03-26 19h50.06 utc:5861: manage_update_nvt_cache_osp: failed to get scanner_version
lib  osp:WARNING:2020-03-26 19h50.16 utc:5897: osp_get_vts_version: element VTS missing.
md manage:WARNING:2020-03-26 19h50.16 utc:5897: manage_update_nvt_cache_osp: failed to get scanner_version

Scanning fails
md manage:WARNING:2020-03-26 19h45.07 UTC:4789: OSP start_scan 26a0b7c5-3074-4af4-a455-102dd0cecfd3: VTs list is empty

bvanh · March 27, 2020, 8:07am

Where’s the config of gvmd stored?

I want to reset the scanner config, I have removed it by gvmd --delete-scanner=<uuid>, checked the psql DB and done a redish flushall but still gvmd logs entries as:

md manage:WARNING:2020-03-27 08h05.56 utc:8419: manage_update_nvt_cache_osp: failed to connect to /opt/gvm/var/run/ospd.sock

While this was the path of my removed scanner, the default scanner is set to /tmp/ospd.sock.

So, where’s this /opt/gvm/var/run/ospd.sock coming from while my scanner is removed?

bvanh · March 30, 2020, 10:09am

After removing the virtualenv for ospd and openvas and a remove of all feed data, and a full Postgressql DB reset, I no longer have this error and all feeds gets imported.

I now have a full functional setup!