About

OpenVAS
Constitution
OpenVAS-Server
OpenVAS-Client
OpenVAS NVT Feed

Information/Howto's

Integrated tools
Security info sources
NVT creation process
Trusted NVTs
Local Security Checks
NVT Feed Services
OpenVAS Compendium (en)
OpenVAS Compendium (de)

Support

Mailinglist Discussion:
Archive | Subscribe
Mailinglist Announcements:
Archive | Subscribe

Online Chat

Professional Services

Developers Corner

Development Platform
Code quality
Change requests
Internal Architecture
Assigning OIDs for NVTS

Mailinglist Development:
Archive | Subscribe
Mailinglist Writing NVTs:
Archive | Subscribe
Mailinglist Packaging/Distributing:
Archive | Subscribe
Mailinglist Source Code Commits:
Archive | Subscribe

Download

Client:
OpenVAS-Client 1.0.4

Server components:
openvas-libraries 1.0.2
openvas-libnasl 1.0.1
openvas-server 1.0.2
openvas-plugins 1.0.4

Documentation:
OpenVAS Compendium 1.0-rc2
PDF (en)
PDF (de)

OpenVAS 2.0 BETA:
openvas-libraries 2.0-beta2
openvas-libnasl 2.0-beta2
openvas-server 2.0-beta2
openvas-client 2.0-beta2
openvas-plugins: Use openvas-plugins 1.0.4

NVT Lookup by OID

(replace 61039 by any other old-style ID)

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

Status: Voted +4.

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 the openvasd's knowledge base (read-only) to retrieve information gathered by other NVTs. Results are returned to openvasd for writing it into the knowledge base. The rest of the this section explains the potential problems and proposed solutions in more detail.

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 will have to reimplement the tests ovaldi performs so that they use the knowledge base instead. This can be done relatively easily as described in the section "OpenVAS Probes in ovaldi" below.

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. The OVAL definitions for RedHat systems, for instance, include tests that check whether a given RPM was cryptographically signed with a specific key. This information can be retrieved from the RPM database on the remote system, but OpenVAS currently does not do that.

Also, at first we would probably not implement all the tests that OVAL supports, 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, ovaldi will have to report the metadata of the individual tests to openvasd too. The metadata include the descriptions of the tests, which systems are affected, what the vulnerability is, references to CVEs, etc. Since ovaldi includes this metadata in the reports it generates, it shouldn't be difficult to report this information to openvasd, too.

However, it should be possible to extract this information from the descriptions before actually running the tests so that the OpenVAS client can show a list of the tests to let the user select which subset of tests to run.

The technical details of this are outlined in "Ovaldi Reporting Back to OpenVAS" below.

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:

OpenVAS Probes in ovaldi

The ovaldi sources are organized into several components:

Each of the platform specific probes directories contains a class called ProbeFactory which is used to instantiate the objects implementing the actual tests. Which probe factory is used simply depends on which one is linked into the final executable. The directory with the platform independent probes doesn't have a probe factory. The platform specific factories instantiate the platform independent probes too.

This design of course implies that a single ovaldi executable can only execute the OVAL descriptions for one platform. Given the intended way ovaldi operates -- running on the system which is to be tested -- this is not a limitation, though.

To get ovaldi to access the OpenVAS knowledge base we can simply treat OpenVAS as a new platform and introduce a new probe factory that instantiates probes that refer to the knowledge base instead of the local system.

Ovaldi Reporting Back to OpenVAS

When integrated with OpenVAS, ovaldi needs to report metadata and test results back to openvasd. The general approach to this would be to replace the code that generates the XML based reports with code that transmits the information to openvasd. We will likely have to replace the main driver code (src/Main.cpp) with our own version, because the current implementation hard-wires too much of the reporting for our purposes. It should not be difficult to simply link with our version of Main.cpp instead of the one coming with ovaldi.

Implementation TODOs

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

History