Security audits

In your environment, you might have employed a combination of security analysts (penetration and application testers) and software applications to find security vulnerabilities in the BMC Discovery virtual appliance. The virtual appliance consists of CentOS and the BMC Discovery application software. 

The goal of this page is to help you understand your security audits to identify items that are valid, false positives, or those that are incorrectly reported as vulnerabilities. 

Operating System Audit

BMC Discovery customers typically run a 3rd party application to determine if there are any vulnerabilities in the OS. These tools, such as Qualys, eEye Digital Security Retina, and Tenable Nessus, check the versions of the packages installed against a known database of vulnerabilities. This database is a combination of their companies' intellectual property and those in the public vulnerability databases such as the Common Vulnerability Engine (CVE) - maintained by the MITRE corporation) and the National Vulnerability Database (NVD).

There are tools that are not aware of the method Red Hat uses to apply functionality and security fixes. As a standard, Red Hat chooses a fixed point to release a new major version, for example, RHEL 5.0. All packages included in the release are then fixed at the level of functionality available upstream at the time and Red Hat will only apply fixes to the versions. Upstream is the term used to refer to the open source projects that do the development work on the packages employed in Red Hat, such as the kernel.

For example, the ssh package for RHEL 5.0 is at version 4.3p2-36.el5. Red Hat have applied a number of fixes to this and the version at RHEL 5.7 is 4.3p2-72.el5_7.5.el5. Notice that the functionality version, 4.3p2, has not changed. The ssh version for RHEL 6.0 is 5.3p1-18.el6 as Red Hat have chosen 5.3p1 to be the base for RHEL 6.

This causes issues with some of the vulnerability assessment tools as they are not "Red Hat aware". Take for example the bzip2 package. The version installed at RHEL 5.7 is 1.0.3-6.el5_5. A vulnerability (CVE, NVD) was found in all versions of bzip2 before 1.0.6 that could cause a Denial of Service (DOS) attack. The tool would identify the fact that the Red Hat installation has version 1.0.3 installed, which appears to have the vulnerability. However, the fix was applied by Red Hat in version 1.0.3-6.el5_5. This is a false positive.

How to determine a false positive in an OS audit

The following examples describe the methodology you should employ in determining whether an alert is a false positive or not.

Example 1

This is an excerpt from the output of a vulnerability reporting tool:

The first step is to check the details on the CVE page. To find this page, check the MITRE CVE site and search for the CVE number. Entering the CVE number (CVE-2009-0688) in a search engine should also find the CVE. The CVE shows that Red Hat has released a statement, a Red Hat Security Advisory (RHSA) describing the vulnerability:

The Red Hat Security Advisory is where Red Hat either release update information, or the Red Hat Bugzilla issue number. In either case, they are generally preceded by REDHAT. Either click the link provided by CVE and search for the RHSA number (RHSA-2009-1116), or search the Red Hat Bugzilla database for the issue number.

The RHSA tells you what version of the package the bug is fixed in.

The edition of Red Hat Linux we are running is referred to as Red Hat Enterprise Linux Server, all other editions can be ignored (Workstation, AS, ES, EUS, Long Life, WS, and so forth). Search for the x86_64 version (Intel/AMD 64-bit). See the example below:

The details or descriptions provided in the RHSA and CVE contain much useful information. Often Red Hat will provide reasons why the specific package is affected. Occasionally the CVE will indicate that the issue is with a specific package, as shown in this example where the CVE states that the Cyrus SASL library that has the issue. Red Hat, however, has fixed the issue in the cyrus-imapd package rather than the cyrus-sasl package, the detail of which is described in the RHSA details section.

Now that the version of the package in which Red Hat has fixed the vulnerability is known, we must confirm that the package is updated in the latest version of BMC Discovery. In the following example, we can check whether or not the packages are installed. As all the affected packages listed on the RHSA page start with cyrus-imapd it is simple to search the entire RPM database and grep for the prefix rather than search individually:

tideway@disco01 ~]$ 
tideway@disco01 ~]$ rpm -qa | grep cyrus-imapd
tideway@disco01 ~]$ 

The package does not appear to be installed. Performing a wider search just for cyrus shows the cyrus packages installed:

tideway@disco01 ~]$ 
tideway@disco01 ~]$ rpm -qa | grep cyrus
cyrus-sasl-lib-2.1.22-5.el5_4.3
cyrus-sasl-lib-2.1.22-5.el5_4.3
cyrus-sasl-devel-2.1.22-5.el5_4.3
cyrus-sasl-plain-2.1.22-5.el5_4.3
cyrus-sasl-2.1.22-5.el5_4.3
cyrus-sasl-plain-2.1.22-5.el5_4.3
tideway@disco01 ~]$ 

The cyrus-imapd package is not installed, so the issue cannot affect BMC Discovery. This issue can be reported as a false positive.

Example 2

Sometimes, it is not immediately obvious whether or not the issue affects Red Hat and careful attention needs to be paid to the CVE detail.

This is an excerpt from the output of a vulnerability reporting tool:

The first step is to check the details on the CVE page. Immediately it is evident that there is no REDHAT entry listed. The closest thing is Fedora which is another Linux distribution sponsored by Red Hat.

The report states that we should upgrade to version 0.9.8n or later. The following example shows checking the version currently installed.

tideway@disco01 ~]$ 
tideway@disco01 ~]$ rpm -q openssl
openssl-0.9.8e-20.el5
openssl-0.9.8e-20.el5
tideway@disco01 ~]$ 

In this example, the same version of the package is listed twice. This occurs when both 32 and 64-bit packages are installed.

The version running is 0.9.8e, which is definitely earlier than 0.9.8n, the version the CVE recommends. Red Hat however has not provided a fix. Possibly one was never required. A careful reading of the CVE description offers a clue.

The ssl3_get_record function in ssl/s3_pkt.c in OpenSSL 0.9.8f through 0.9.8m allows remote attackers to cause a denial of service (crash) via a malformed record in a TLS connection that triggers a NULL pointer dereference, related to the minor version number.

According to the CVE description, the vulnerability exists in versions 0.9.8f through 0.9.8m. The virtual appliance is running version 0.9.8e so the vulnerability that was created in the changes from e to f does not affect our version. Again, the issue cannot affect BMC Discovery and can be reported as a false positive.