After update to OpenVAS 9 scans do not run

[melauer]

A few days ago I updated OpenVAS on a RedHat Enterprise Linux 7.4 system using yum. The system is set up to use to the AtomicCorp repo. While the OpenVAS web interface still works and allows me to modify targets, request scans, etc. any requested scans never get past "Requested" status.

After turning up the debug levels in openvasmd_log.conf I found this error in the logs:

Code: Select all

md manage:  DEBUG:2017-08-11 09h48.15 EDT:9662:    sql: SELECT * FROM (WITH users_with_access ("user") AS (VALUES (1))  SELECT DISTINCT min_qod, override, "user"  FROM report_counts  WHERE report = 388    AND "user" IN (SELECT "user"                     FROM users_with_access)    AND min_qod <= 2147483647  UNION SELECT 0 as min_qod, 0, "user"          FROM users_with_access  UNION SELECT 0 as min_qod, 1, "user"          FROM users_with_access  UNION SELECT 70 as min_qod, 0, "user"          FROM users_with_access  UNION SELECT 70 as min_qod, 1, "user"          FROM users_with_access) AS inner_query ORDER BY "user"
md manage:WARNING:2017-08-11 09h48.15 EDT:9662: sql_prepare_internal: sqlite3_prepare failed: near "(": syntax error
md manage:WARNING:2017-08-11 09h48.15 EDT:9662: init_iterator: sql_prepare failed
md manage:WARNING:2017-08-11 09h48.15 EDT:9662: manage_cleanup_process_error: Error exit, setting running task to Internal Error

The scans just sit there at "Requested" for a while and then go to "Stopped". Looking at the reports I see that they all have status "Internal Error" which matches what the error log says. Aside from this OpenVAS seems to be running fine. The openvas-check-setup script seems to think that my install is okay:

Code: Select all

root@openvas:~ # openvas-check-setup --v9
openvas-check-setup 2.3.7
  Test completeness and readiness of OpenVAS-9

  Please report us any non-detected problems and
  help us to improve this check routine:
  http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss

  Send us the log-file (/tmp/openvas-check-setup.log) to help analyze the problem.

  Use the parameter --server to skip checks for client tools
  like GSD and OpenVAS-CLI.

Step 1: Checking OpenVAS Scanner ... 
        OK: OpenVAS Scanner is present in version 5.1.1.
        OK: redis-server is present in version v=3.2.3.
        OK: scanner (kb_location setting) is configured properly using the redis-server socket: /tmp/redis.sock
        OK: redis-server is running and listening on socket: /tmp/redis.sock.
        OK: redis-server configuration is OK and redis-server is running.
        OK: NVT collection in /var/lib/openvas/plugins contains 54512 NVTs.
        WARNING: Signature checking of NVTs is not enabled in OpenVAS Scanner.
        SUGGEST: Enable signature checking (see http://www.openvas.org/trusted-nvts.html).
        OK: The NVT cache in /var/cache/openvas contains 55114 files for 54512 NVTs.
Step 2: Checking OpenVAS Manager ... 
        OK: OpenVAS Manager is present in version 7.0.2.
        OK: OpenVAS Manager database found in /var/lib/openvas/mgr/tasks.db.
        OK: Access rights for the OpenVAS Manager database are correct.
        OK: sqlite3 found, extended checks of the OpenVAS Manager installation enabled.
        OK: OpenVAS Manager database is at revision 184.
        OK: OpenVAS Manager expects database at revision 184.
        OK: Database schema is up to date.
        OK: OpenVAS Manager database contains information about 54512 NVTs.
        OK: At least one user exists.
        OK: OpenVAS SCAP database found in /var/lib/openvas/scap-data/scap.db.
        OK: OpenVAS CERT database found in /var/lib/openvas/cert-data/cert.db.
        OK: xsltproc found.
Step 3: Checking user configuration ... 
        OK: The password policy file at /etc/openvas/pwpolicy.conf contains entries.
Step 4: Checking Greenbone Security Assistant (GSA) ... 
        OK: Greenbone Security Assistant is present in version 7.0.2.
        OK: Your OpenVAS certificate infrastructure passed validation.
Step 5: Checking OpenVAS CLI ... 
        OK: OpenVAS CLI version 1.4.5.
Step 6: Checking Greenbone Security Desktop (GSD) ... 
        SKIP: Skipping check for Greenbone Security Desktop.
Step 7: Checking if OpenVAS services are up and running ... 
        OK: netstat found, extended checks of the OpenVAS services enabled.
        OK: OpenVAS Scanner is running and listening on a Unix domain socket.
        OK: OpenVAS Manager is running and listening on a Unix domain socket.
        WARNING: Greenbone Security Assistant is listening on port 8080, which is NOT the default port!
        SUGGEST: Ensure Greenbone Security Assistant is listening on one of the following ports: 80, 443, 9392.
Step 8: Checking nmap installation ...
        WARNING: Your version of nmap is not fully supported: 6.47
        SUGGEST: You should install nmap 5.51 if you plan to use the nmap NSE NVTs.
Step 10: Checking presence of optional tools ...
        OK: pdflatex found.
        WARNING: PDF generation failed, most likely due to missing LaTeX packages. The PDF report format will not work.
        SUGGEST: Install required LaTeX packages.
        OK: ssh-keygen found, LSC credential generation for GNU/Linux targets is likely to work.
        OK: rpm found, LSC credential package generation for RPM based targets is likely to work.
        OK: alien found, LSC credential package generation for DEB based targets is likely to work.
        OK: nsis found, LSC credential package generation for Microsoft Windows targets is likely to work.
        OK: SELinux is disabled.

It seems like your OpenVAS-9 installation is OK.

If you think it is not OK, please report your observation
and help us to improve this check routine:
http://lists.wald.intevation.org/mailman/listinfo/openvas-discuss
Please attach the log-file (/tmp/openvas-check-setup.log) to help us analyze the problem.

I'm not an expert on SQLite so perhaps this is a red herring but one thing I notice is that there is no users_with_access table in tasks.db even though the query seems to refer to one. Aside from that I have tried regenerating my certificates but this did not help. Any other thoughts on what could be the problem?

[melauer]

I found a workaround for the issue. Downgrading from openvas-manager 7.0.2 to 7.0.1 seems to have fixed it. In this case since I'm on RedHat Enterprise Linux 7.4 this was easy:

Code: Select all

yum downgrade openvas-manager
systemctl restart openvas-manager.service