Blog

Creating SVM Exceptions in Halo: Part 1

The Software Vulnerability Management (SVM) system within Halo checks the software installed on your servers for any known vulnerabilities. Occasionally however, you may run across a software package that is labeled as vulnerable, when in fact it is not. This is referred to as a “false positive”. In this two part blog series post I’ll first discuss how false positives can occur, and then cover what you can do to clear them within Halo.

Where Does Halo Get its Vulnerability Information?

Halo checks in daily with the National Vulnerability Database (NVD) to see what vulnerability information has been posted. The database contains a list of all publicly known vulnerabilities.  Each vulnerability is assigned a unique CVE number by MITRE or some other registered CVE Numbering Authority (CNA). The CVE numbers ensure that each vulnerability has a unique way of identifying it. The database is considered to be the central location where software vulnerabilities get listed and tracked. CloudPassage, like most security vendors, leverages this database for vulnerability information.

Disputed Entries

One possible false positive condition is a disputed entry. For example if you are running an Ubuntu based system you may see the “screen” package get flagged with CVE identifier CVE-2007-3048. If you check the NIST entry for this vulnerability, you will see that this entry was created in 2007, and that multiple third parties have attempted and failed to reproduce this problem. In other words, in over four years no one else has been able to corroborate this vulnerability. Since the software authors were unable to reproduce the problem, they were obviously unable to create a fix. So this NVD entry is unlikely to ever be closed.

So technically this is still a valid entry as a fix has never been released. However if only the original reporter was able to produce this vulnerability condition, one has to wonder if perhaps the problem was actually with their setup, and not with the software itself. So if we feel the lack of corroboration over such an extended period of time is an indication that the entry is in fact false, we would consider this vulnerability to be a false positive.

Backported Patches

Another condition that can cause false positives is the backporting of patches. For example let’s say I maintain the “fubar” software package and it is currently shipping at version 1.2. Let’s further assume that a vulnerability is found in the software, which I then fix in release 1.3. Typically if you were to upgrade your software to 1.3, you would avoid any possible false positive condition.

The problem tends to occur when software distributors get involved. For example let’s say that my 1.3 version release also makes some interface or API changes. If Red Hat is distributing my “fubar” package, they may not want to push through the 1.3 release as the interface and API changes could have a negative impact on their clients who are not ready for the changes. So Red Hat may choose to create a new version, say “1.2-p1”, which contains just the fix for the vulnerability.

This is where things get messy. If the NIST database identifies that you must be running version 1.3 to be safe from this vulnerability, systems running version 1.2-p1 willl get labeled as vulnerable. So even though you are actually safe from this vulnerability, because the software version information does not match a false positive condition gets generated.

Checking For Backported Patches

Let’s walk through an example of how you can identify when a backported patch is creating a false positive. Note in Figure 1 Halo has identified the “expat.x86_64” package as being vulnerable to two separate issues. Each issue is being identified by a unique CVE reference number. These vulnerabilities were identified on a fully patched Fedora 16 server.

The first thing that jumps out at me is that both vulnerabilities are from 2009. Fedora 16 was recently released, and it is unlikely the distribution would have shipped with two known vulnerabilities that are at least two years old. So this initial sanity check makes me wonder if there is not a problem with version numbers. If I click on the first CVE number, I can get details on this vulnerability as shown in Figure 2.

Note the detailed information identifies that version 2.0.1 of the software is vulnerable, and referring back to Figure 1 we can see that this is the version being reported by the software. If we scroll to the bottom of the screen, we’ll see that Halo provides a number of external references for more information. An example is shown in Figure 3.

Since we’re running a Fedora system, the best place to start is with one of the Fedora links shown above. Clicking on the “msg00413.html” link (third under external references) brings up a Fedora security post. Of interest, is the section shown in Figure 4. Note in the “ChangeLog” section of the post states that the fix was backported to version 2.0.1-8, and that both of the CVE numbers shown in Figure 1 were addressed in this fix.

Checking Package Versions

So now we know that if we are at least running 2.0.1-8, we are safe from these vulnerabilities. The next thing we need to do is identify exactly what version of the software we are running. On a Fedora based system, we can do this with the “rpm” command as follows.

[cbrenton@fedora-16 ~]$ sudo rpm -q expat.x86_64
expat-2.0.1-11.fc15.x86_64

Note the reported version is 2.0.1-11, which is a higher revision than 2.0.1-8 under which the patch was released. So this tells us that we are in fact safe from the two listed vulnerabilities.

When we identify a false positive, we’ll want to create an exception for it within Halo so that the vulnerability report does not keep appearing. I’ll cover how to do that in part two of this series.

Stay up to date

Get the latest news and tips on protecting critical business assets.

Related Posts