Detecting Vulnerable Software Using SCAP/OVAL

Thursday, April 07, 2011

Jamie Adams


In a few of my previous posts, I discussed misleading results some scanners might produce with regard to the versions of software present on your system.

In this post, I will demonstrate how to use an SCAP capable scanner using vendor-maintained OVAL patch definitions.

In order to assess my system, I need an OVAL-capable scanner and data it can use to assess my system against. Let's start by downloading the source code to the OpenSCAP scanner.

Once downloaded, I'll build the scanner on my openSUSE 11.1 system:

# /bin/tar xzvf openscap-0.7.0.tar.gz
# cd openscap-0.7.0/
# ./configure --prefix=/usr
# /usr/bin/make
# /usr/bin/make install

Next I need some appropriate content the scanner can use to assess my system. Since I am running openSUSE 11.1, I need to get my specific OVAL patch definitions from Novell. I simply use curl to get the exact file:

# /usr/bin/curl -O

Now, use the OpenSCAP command utility to assess the system and write the results to a file:

# /usr/bin/oscap oval eval --result-file ./myresults.xml ./opensuse.11.1.xml

Evalutated definition false
Evalutated definition false
Evalutated definition false
Evaluation: All done.
====== RESULTS ======
TRUE: 36
FALSE: 1162

The last step is to create an HTML-formatted report from the results file:

# /usr/bin/oscap oval generate report \
--output ./howamidoing.html ./myresults.xml

The report could do a better of job of correlating the reference identification to the actual vulnerable software. According to OpenSCAP's website, this is on their “to-do” list.

The OVAL patch definitions comprise a definition which identifies the tests to be performed. The tests determine if an object is in a particular state. Let's consider a real world example and then we'll walk through the OVAL definition.

A port scanner detects an Apache web server running:

# /usr/bin/nmap -sV -p 80 localhost
Starting Nmap 4.75 ( ) at 2011-04-06 08:32 EDT

Interesting ports on localhost (
80/tcp open http Apache httpd 2.2.10 ((Linux/SUSE))

Service detection performed.
Please report any incorrect results at .
Nmap done: 1 IP address (1 host up) scanned in 6.17 seconds  

From this the security officer believes it is vulnerable to CVE-2009-1195. Within minutes, they communicate the issue and demand the web server be shut down because it is not at least version 2.2.12!

The Nessus vulnerability scanner also reports version 2.2.10 however, its plug-in (#39521) Backported Security Patch Detection (WWW) reports a low-severity problem. Better than a false-positive but it still means that you'll need to investigate your installed version to see if it has been patched correctly.

At this point, the system administrator verifies the package installed is version 2.2.10-2.9.1:

# /bin/rpm -q apache2

However, the package's change log and a scan performed using the vendor-maintained OVAL definitions reports it is okay. This is effective because the vendor knows when the problem was patched (backported security fixes) and it is defined in the OVAL data file. Here is Novell's definition: (Click image to enlarge)



The definition's criteria includes a test (...:tst:2009055744) to determine if the Apache package is less than 2.2.10-2.8.1. The test itself evaluates the object (...:obj:2009030668) to determine if it is installed and in a specific state (...:ste:2009037265): (Click image to enlarge)



The object is an RPM package object and the name of the package is “apache2”: (Click image to enlarge)



Finally, if the package object's epoch-version-string (EVR) is less than 0:2.2.10-2.8.1 then the test is true and the installed software is vulnerable. (Click image to enlarge)



However, our system is not vulnerable because we have 2.2.10-2.9.1 installed on the system. Too often system administrators believe they must build and maintain their own version of the Apache web server because they think the vendor's package is out-of-date and vulnerable.

Unfortunately, in some cases they just want to avoid the heartburn and frustration which comes with trying to explain to auditors and security officers that they are not vulnerable.

I have found that OVAL patch definitions are useful and accurate. However, if vendors don't maintain them, you'll have to do some more digging.

And of course, if the software isn't installed as a package, you'll have to dig even more. Overall, I am impressed with OpenSCAP and am excited about the growing OVAL repositories.

Cross Posted from Security Blanket Technical Blog

Possibly Related Articles:
Software Vulnerabilities Scanners OpenSCAP OVAL Nessus
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.