Our ability to protect our systems from vulnerabilities is often only as good as the information available to us. One source, OVAL definitions, promises to “provide enterprises with accurate, consistent, and actionable information so they may improve their security.” Unfortunately, blindly trusting that this data is accurate could still leave your systems vulnerable. Recently, when I was reviewing our Red Hat coverage against some older Red Hat OVAL definitions, I encountered several significant inconsistencies between our coverage and the OVAL definition. After completing the comparison, two notable issues stood out to me:
- For many advisories, where we had coverage for a given vulnerability on Red Hat Enterprise Linux 5 (RHEL 5), the OVAL definition didn’t identify any vulnerable packages.
- In several instances, our CVE for an advisory was completely different than the one listed in the OVAL definition.
My first thought was that the OVAL definition had been incorrect when it was released and had been later updated by Red Hat, meaning the current data was correct. Perhaps RHEL 5 wasn’t vulnerable to the CVEs covered by those vulnerabilities? Maybe the CVEs had been made obsolete and a new CVE better represented the vulnerability? Given the sheer number of advisories that no longer included RHEL 5, I began to question the accuracy of the OVAL definitions. Since I’ve seen many instances where the CVE for a vulnerability has been updated, I was initially less concerned with the second issue. It’s common for CVEs to change when the initial report covers multiple vulnerabilities that are eventually split into their own individual CVEs, thereby rendering the original CVE obsolete. Certainly, this could have been the case here. For the first issue, we’ll look at advisory RHSA-2011:0885 The CPE reference to RHEL 5 is the only indication in the OVAL definition that it is included in this advisory. It could be a mistake that it’s listed there, but another source, the advisory web page, also mentions RHEL 5 in the ‘Affected Products’ list. It also contains a list of updated packages for RHEL 5, which is missing from the OVAL definition. From this, it seems pretty likely that RHEL 5 is affected by the vulnerabilities described in advisory RHSA-2011:0885. The OVAL definition is clearly missing important information. Now that I was reasonably sure some OVAL definitions were missing data, I took a closer look at the second issue. In advisory RHSA-2014:0624, the OVAL XML originally referenced CVE-2014-0224, but the newer XML referenced CVE-2014-0226. The package updated by the advisory is openssl, so a look at the CVE descriptions should give a good indication of which CVE is correct for this advisory. CVE-2014-0224 Description:
"It was found that OpenSSL clients and servers could be forced, via a specially crafted handshake packet, to use weak keying material for communication. A man-in-the-middle attacker could use this flaw to decrypt and modify traffic between a client and a server."
"A race condition flaw, leading to heap-based buffer overflows, was found in the mod_status httpd module. A remote attacker able to access a status page served by mod_status on a server using a threaded Multi-Processing Module (MPM) could send a specially crafted request that would cause the httpd child process to crash or, possibly, allow the attacker to execute arbitrary code with the privileges of the 'apache' user."
The updated CVE isn’t related to openssl, which makes it likely that the new CVE listed in the OVAL XML is incorrect. So why were OVAL definitions that were once right, updated with incorrect information? Only Red Hat can really answer that question, but, if we look at the Red Hat OVAL repository, it shows that all the definitions were updated on October 20, 2015. As they’ve been updated since their originally creation, this is likely the point where the issues I encountered were introduced. OVAL definitions are usually correct, but they, much like any other data source, can contain erroneous information. Although the OVAL feeds from Red Hat can generally be used to confirm if vulnerabilities exist or not, in the cases we saw here, relying on them could have left RHEL 5 systems vulnerable. To avoid creating a false sense of security by thinking systems are patched when they aren’t, you should verify that the data you are using is correct. A great way to help with this verification process without having to manually and tediously review each advisory is to use a vulnerability scanner. In these cases, scanning a RHEL 5 system with Tripwire’s IP360. Title image courtesy of ShutterStock
