English | Deutsch
Home »

OpenVAS Change Request #13: Integrating the OVAL interpreter ovaldi into OpenVAS Server

Status: Voted +4. Done. A proof-of-concept has been implemented and is included in OpenVAS since 2.0-beta1.

Purpose

To have OpenVAS Server treat and execute OVAL tests analog to NASL tests (though done via ovaldi and being aware it will only be possible for a subset of OVAL tests) and use the feed service for distributing new OVAL tests.

References

General information about OVAL (http://oval.mitre.org/)
The ovaldi Interpreter

Rationale

OVAL -- Open Vulnerability and Assessment Language -- is an XML-based language for descriptions of vulnerability tests (among other things). As such its scope overlaps to a large extent with OpenVAS NVTs and it would be very useful to have some sort of support for OVAL in OpenVAS. OVAL vulnerability definitions for a variety of systems are available from mitre.org, and at least RedHat also publishes security advisories in OVAL form.

Integrating an OVAL interpreter in OpenVAS in some form would make OVAL descriptions more or less automatically usable with OpenVAS. E.g. if a vendor releases all security advisories as OVAL descriptions corresponding checks would be available for OpenVAS immediately without having to write new NASL scripts. However, for the time being it is expected to have at least the local security checks work this way, which is an area for which currently most OVAL tests are published.

Effects

These effect only apply for users who configure OpenVAS to use ovaldi.

Design and Implementation

The ovaldi interpreter will be run as a sub-process of openvasd and be able to access information gathered by OpenVAS and prepared in the form of an OVAL System Characteristics file. The OpenVAS server returns the results of the ovaldi run to the client along with the results of other NVTs.

Run Tests Against the OpenVAS Knowledge Base

OpenVAS runs as a server that performs security checks on remote systems, whereas ovaldi is intended to be run on the system to be checked. This fundamental difference means that ovaldi examines the local system to check whether the criteria of an OVAL definition match the system, accessing local files directly or querying the system's database of installed software packages. OpenVAS, on the other hand, typically runs some NASL scripts to detect the remote host's operating system and to e.g. get a list of installed packages. This information is inserted into the knowledge base and individual NVTs later simply query the knowledge base.

We have already reimplemented some tests ovaldi performs so that they use data gathered in the knowledge base instead. This can be done relatively easily by exporting relevant parts of the knowledge base into a format ovaldi can understand, for example one conforming to the System Characteristics schema mentioned above.

Of course, tests run against the knowledge base will not be able to run tests that need information not currently available from the knowledge base.

Also, we do not implement all the tests that OVAL supports from the beginning, only the ones we need for the subset of OVAL definitions we support initially.

Report Test Results to openvasd

Per default ovaldi outputs the results of the tests in the form of XML files and also generates an HTML file from those. To be usable for OpenVAS it would be necessary to report the results back to the openvasd. The technical details of this are outlined in "Ovaldi Reporting Back to OpenVAS" below.

Reporting Metadata

In addition to results, openvasd needs to be able to read the metadata of the individual OVAL definitions in order to communicate them to the client and to allow the client to select the definitions which should be executed. This can be done relatively easy by parsing the XML files containing the individual definitions and transmitting them to the client similar to the way this is done with NASL- or NES-based NVTs.

Map OVAL IDs to OpenVAS OIDs

NVTs are identified by OIDs within OpenVAS (once Change Request #1 is implemented). OVAL descriptions are identified by an ID which is a character string of the form:

  oval:<reverse domain>:def:<num>

Where <reverse domain> is a domain name in reverse order, for instance org.openvas instead of openvas.org. and <num> is an integer. Since the OVAL IDs are a completely new namespace, we should introduce a new OID sub-tree for them, e.g. (following Change Request #1):

   1.3.6.1.4.1.25623.1.2 
      = iso.org.dod.internet.private.enterprise.OpenVAS.NVT.OVAL

Below that we need one level for each of the domains that occur in OVAL IDs and then another below that for the domain specific <num>s. The main problem then is how to map the domain names to numbers.

In practice there will only be a few publishers of OVAL definitions. Currently most come from oval.mitre.org. We could either assign the numbers ourselves (org.mitre.oval -> 1, com.redhat.rhsa -> 2, etc.) or we could reuse the OIDs the publishers already have in the private enterprise OID namespace. Reusing the private enterprise OIDs would lead us to the following examples:

OVAL IDOpenVAS OID
oval:org.mitre.oval:def:5327 1.3.6.1.4.1.25623.1.2.115.5327
oval:com.redhat.rhsa:def:20080177 1.3.6.1.4.1.25623.1.2.2312.20080177

In any case, we need to maintain an explicit mapping between the domains used in OVAL IDs and the domain-numbers used in OpenVAS OIDs. The mapping between domains and OIDs is not unambiguous because a vendor could start to use more than one domain name for OVAL IDs. However, reusing vendor OIDs for OpenVAS NVT OIDs in the fashion described above has the advantage that OpenVAS users trying to use OVAL definitions from a new source could derive the correct OID on their own if necessary.

Integrity Check of OVAL Definitions

OpenVAS uses OpenPGP signatures to check the integrity of NASL files and will not run any NASL file that does not have a valid signature from a trusted key. Something like this would be desirable for the OVAL definitions too. The easiest way to support it would be to use the same signature mechanism as for NASL scripts and have openvasd check the signatures before starting the oval interpreter.

ovaldi has an integrity check built in, though. It compares the md5sum of the file with an md5sum given on the command line. It would be possible to extend ovaldi to do the OpenPGP signature check instead of having openvasd do it.

Changes to openvasd

openvasd will run ovaldi as a sub-process.

Potential problems:

Ovaldi Reporting Back to OpenVAS

When integrated with OpenVAS, ovaldi needs to report metadata and test results back to openvasd. This is done by parsing the XML results file generated by ovaldi and the sending the relevant information to the client.

Implementation

This is a unsorted initial collection of explicit changes/extensions to the code:

Right now, it is necessary to use a patched version of ovaldi due to limitations in the current ovaldi version regarding the parsing of System Characteristics files. More details can be found on the Integrated Tools page.

History