OpenVAS Security Advisory (OVSA20131108)
Date: 8th November 2013
Product: OpenVAS Manager < 3.0.7 and < 4.0.4 and OpenVAS Administrator < 1.2.2 and < 1.3.2
Vendor: OpenVAS <http://www.openvas.org/> Risk: Low
It has been identified that OpenVAS Manager and OpenVAS Administrator are vulnerable to authentication bypass due to an incorrect state assignment when processing OMP and OAP requests. It has been identified that this vulnerability may allow unauthorised access to OpenVAS Manager and OpenVAS Administrator on vulnerable systems. CVE-2013-6765 has been assigned to this vulnerability in Manager and CVE-2013-6766 to the same vulnerability in Administrator.
It should be noted that not all of the newly available commands are functional and that exploitation typically requires SSH access to the host on which the services are installed.
As of the 8th November, the state of the vulnerabilities is believed to be as follows. Patches have been supplied by Greenbone Networks which it successfully resolves this vulnerability. New releases of both OpenVAS Manager and OpenVAS Administrator have also been created which incorporate these patches.
It has been identified that OpenVAS Manager and OpenVAS Administrator are vulnerable to authentication bypass due to an invalid state assignment when processing OMP and OAP requests.
Upon processing an OMP and OAP request to retrieve the version information from OpenVAS Administrator and OpenVAS Manager, the state is incorrectly set to CLIENT_AUTHENTIC, allowing additional OMP and OAP commands to be called. This can be seen in the omp_xml_handle_end_element() function from omp.c (for OpenVAS Manager):
if (client_state) set_client_state (CLIENT_AUTHENTIC); else set_client_state (CLIENT_TOP); break;
In this instance, the first condition will always hold. Rather, the check should be whether client_state is currently set to CLIENT_GET_VERSION_AUTHENTIC.
It should be noted that not all of the newly available commands are functional, since they often rely upon additional session state information being present which will not be the case where the authentication has been bypassed.
Furthermore, the vulnerable code path is typically only accessible to users who have logged into a host running OpenVAS Manager or OpenVAS Administrator via SSH as the affected services are typically only bound to localhost.
OpenVAS recommends that the publicly available patches are applied. If building from source, then patches r18285 (for OpenVAS Administrator 1.2.x) or r18281 (for Administrator 1.3.x) and r18276 (for OpenVAS Manager 3.0.x) or r18271 (for Manager 4.0.x) should be obtained from the OpenVAS SVN repository.
A fresh tarball containing the latest stable release of Administrator can be obtained from:
A fresh tarball containing the latest stable release of Manager can be obtained from:
In the event that OpenVAS has been supplied as part of a distribution then the vendor or organisation concerned should be contacted for a patch. Known major distributors of OpenVAS precompiled packages have already been notified.
On the 3rd August 2013, Antonio Sanchez Arago initially attempted to contact the OpenVAS security team to report the issue in OpenVAS Manager however it was missed as many of the team were on annual leave.
Unfortunately, it was not picked up until Antonio attempted to contact us again on in late October. On this occasion, it was picked up and the team were able to reproduce the vulnerability.
On the 7th November, we contacted Antonio to confirm that the team had successfully reproduced the issue and Greenbone Networks to notify them of the vulnerability and request assistance in coordinating the disclosure. Major distributors of OpenVAS precompiled packages were also notified about the upcoming patches.
New versions of both OpenVAS Manager and OpenVAS Administrator were released on the 8th.
The OpenVAS security team then contacted MITRE and on the 9th November, CVE-2013-6764 and CVE-2013-6766 were assigned for this vulnerability.
OpenVAS would like to thank Antonio Sanchez Arago of INTECO for his help in reporting the vulnerability and apologise to all concerned for the substantial delay in triaging his report.