Third-party severity ratings
The National Vulnerability Database provides a public severity rating for all CVE named vulnerabilities, "Low" "Medium" and "High", which they generate automatically based on the CVSS score their analysts calculate for each issue. I've been interested for some time to see how well those map to the severity ratings that Red Hat give to issues. We use the same ratings and methodology as Microsoft and others use, assigning "Critical" for things that have the ability to be remotely exploited automatically through "Important", "Moderate", to "Low".
Given a thundery Sunday afternoon I took the last 12 months of all possible vulnerabilities affecting Red Hat Enterprise Linux 4 (from 126 advisories across all components) from my metrics page and compared to NVD using their provided XML data files. The result broke down like this:
So that looked okay on the surface; but the diagram above implies that all the issues Red Hat rated as Critical got mapped in NVD to High. But that's not actually the case, and when you look at the breakdown you get this result: (in number of vulnerabilities)
That shows nearly half of the issues that NVD rated as High actually only affected Red Hat with Moderate or Low severity. Given our policy is to fix the things that are Critical and Important the fastest (and we have a pretty impressive record for fixing critical issues), it's no wonder that recent vulnerability studies that use the NVD mapping when analysing Red Hat vulnerabilities have some significant data errors.
I wasn't actually surprised that there are so many differences: my hypothesis is that many of the errors are due to the nature of how vulnerabilities affect open source software. Take for example the Apache HTTP server. Lots of companies ship Apache in their products, but all ship different versions with different defaults on different operating systems for different architecture compiled with different compilers using different compiler options. Many Apache vulnerabilities over the years have affected different platforms in significantly different ways. We've seen an Apache vulnerability that leads to arbitrary code execution on older FreeBSD, that causes a denial of service on Windows, but that was unexploitable on Linux for example. But it has a single CVE identifier.
So if you're using a version of the Apache web server you got with your Red Hat Enterprise Linux distribution then you need to rely on Red Hat to tell you how the issue affects the version they gave you -- in the same way you rely on them to give you an update to correct the issue.
I did also spot a few instances where the CVSS score for a given vulnerability was not correctly coded. CVSS version 2 was released last week and once NVD is based on the new version I'll redo this analysis and spend more time submitting corrections to any obvious mistakes.
But in summary: for multi-vendor software the severity rating for a given vulnerability may very well be different for each vendors version. This is a level of detail that vulnerability databases such as NVD don't currently capture; so you need to be careful if you are relying on the accuracy of third party severity ratings.
Comments
Thank you. The RH scoring is great value added. When I read the Erratas and corresponding bugzillas they tend to describe 'the' fix and tell you to fetch and apply a new version . Wouldn't it be useful to also have an additional section that discusses ways to lower the score with a partial (or possibly complete) mitigation? This is more important when a bundle is rated 'High' and the application is not using the vulnerable feature/class/library... and the rest is 'Low' (Java comes to mind). I imagine that in many cases deploying a new version is cheaper than changing a configuration, but in some cases the mitigation would be better practice anyway and possibly already implemented (e.g. turning off SSLv3, not loading mod_status,..).
Hello Fred, sorry for the delay in getting back to you. Thank you for your comment and suggestion! We have been looking into adding mitigation information for flaws when possible, and our CVE pages already display a Mitigation section when one is available. A random example is https://access.redhat.com/security/cve/CVE-2015-6246 . I'll let the team know our customers would like to have more of those. Having said that, I have to apologize for a bug in our blogging platform here at the Customer Portal. This post was actually recently imported into the blog for historical reasons, and the original dates back to 2007, so the data presented is relevant to that timeframe. Unfortunately the blog is showing only the "updated" timestamp, which is misleading, and not the original publication timestamp. This bug is being resolved by our portal developers. Thank you again for your attention!
Hi Fabio, np, thanks for the feedback and the link example link with the Mitigation section.