eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
Today’s Patch Tuesday bulletins announced 11 vulnerabilities: four critical, six important, and one moderate. What do these terms mean?
You see severity ratings most of the time you see a vulnerability disclosure, but there are no hard standards for severity ratings. In fact some vendors-most infamously Apple-don’t provide any severity ratings for their vulnerabilities. Not that Apple is a big issue for many enterprises, but the absence of severity ratings makes it difficult to prioritize patches.
Microsoft’s definitions for their ratings were last updated November 2002, so they’re pretty comfortable with them. Let’s look at the definition of Critical: “A vulnerability whose exploitation could allow the propagation of an Internet worm without user action.” That’s pretty serious stuff. Sounds like Blaster and Code Red. Did four of this month’s vulnerabilities really have the potential to result in Internet worms?
I’ll go out on a limb and say no, but it depends on what you mean by Internet worm. I think of a program which spreads itself around without users taking any action, like Blaster or Slammer. Microsoft uses the term Critical often when user interaction is required.
Microsoft releases Patch Tuesday fixes with new Exploitability Index. Click here to read more.
Consider this month’s critical update MS08-057 (Vulnerabilities in Microsoft Excel Could Allow Remote Code Execution). This describes three vulnerabilities in Excel that result from opening a potentially malicious document. Only on Windows 2000 is it rated critical, since that version does not, by default, include the functionality of the Office Document Open Confirmation Tool for Office 2000, which forces confirmation for opening documents. This is not what makes an “Internet worm.”
In fact, Microsoft has been ignoring its own definition of critical for years, as it should. There haven’t been any real Internet worms for Windows in years, and nobody else restricts their definition of “critical” to such dire circumstances. Microsoft’s Jeff Jones alludes to these points in a blog on severity ratings systems from last year.
I think for most vendors critical means remote code execution, but not to Microsoft, at least not officially. It’s not hard to find Microsoft remote code execution vulnerabilities rated Important, such as MS08-049: Vulnerabilities in Event System Could Allow Remote Code Execution. I think the difference in MS08-049 is that the attacker has to be authenticated, which is a serious limitation in the attack.
Out of Sync
So don’t get me wrong, I think all of these vulnerabilities are properly rated, but it’s the definition that’s out of sync with reality. Microsoft’s real definition of critical seems to be what they define as Important: “A vulnerability whose exploitation could result in compromise of the confidentiality, integrity, or availability of user’s data, or of the integrity or availability of processing resources.” Once again, it depends on how you define terms like “integrity,” but I think it fits. And given the limitation for which Microsoft rated MS08-049 Important, I think its definition of Moderate applies well: “Exploitability is mitigated to a significant degree by factors such as default configuration, auditing or difficulty of exploitation.”
I said before that there are no hard standards for severity ratings, but there are those of NIST, the National Institute of Standards and Technology for the NVD (National Vulnerability Database). The NIST/NVD standards, which are used in calculating CVSS scores, are broken down by a group of metrics, such as Au for the level of authentication needed for exploitation. Au can have the value N for None required, S for Single instance required or M for requires Multiple instances. Other metrics are more qualitative, such as AC for Access Complexity (required attack complexity), where the possible values are H for High, M for Medium or L for Low.
Linux vendors increase security features. Click here to find out more.
I can see the value in the NIST approach. In the end it is used to calculate a CVSS score that could serve the same simple rating role that vendor assertions of severity serve. For instance, the CVSS score for MS08-049, the one Microsoft rated Important, is 9.0 which NIST calls “High.”
The Mozilla definitions can be found at the top of their advisory page. These are easier to understand, but probably a little too specific and simplistic. They have to do a lot of interpretation at times to shoe-horn a vulnerability into one of the definitions. They deal with this by thinking worst-case, which is the right way to do it given their definitions.
Mozilla is often in the habit of noting crash bugs with evidence of memory corruption such as these. They say they have no evidence of exploitability, but neither can they rule out the possibility. They rate these critical, thinking worst-case scenario, as I just said. I’ve never seen another prominent vendor word it this way. I like the honesty of admitting the situation is technically unclear at this point. Microsoft, to my knowledge, doesn’t do that. It would probably just call it a Remote Code Execution vulnerability and decline to elaborate further. Neither vendor, to be sure, is very specific about vulnerabilities in their advisories.
This month Microsoft began providing not just ratings for each vulnerability, but an “exploitability index” score, to show that 1) consistent exploit code is likely, 2) inconsistent exploit code is likely or 3) functional exploit code is unlikely. This adds more detail for those who look at and analyze details, but if it doesn’t feed back into the ratings it may get overlooked.
Comparing Ratings Systems
The Jeff Jones article I mentioned earlier does a good job of comparing vendor ratings systems. Jones shows, for example, that Red Hat’s severity ratings are quite similar to Microsoft’s. That doesn’t mean that Red Hat applies them the same way as Microsoft, although Red Hat previously complained about a Jones analysis, using NVD ratings, showing that they had a high percentage of “High” vulnerabilities. Because it’s sort of a base line, Jones likes using the NVD ratings; in this blog, Jones shows that OS X, Red Hat and Ubuntu had many more and more severe vulnerabilities than Windows XP or Vista (in the first quarter of 2008). He makes a similar point about IE and Firefox in this blog.
Even though he uses it to make a point, Jones says he doesn’t like the NVD/CVSS ratings system. Because of how the scoring works he thinks that it doesn’t necessarily give what should be the higher-priority issues higher scores.
The other major problem with severity ratings that cause them to be overstated is when multiple platforms are affected, to different degrees, in an advisory. Many vendors, including outside parties such as Secunia, apply an overall severity rating to an advisory, which is usually the worst-case severity in the advisory. But depending on your architecture or other specifics, that severity may not apply. Microsoft is commonly guilty of this; a vulnerability which affects you may, for instance, be critical on Windows 2000, but far less severe on Windows XP or Windows Server 2003, and yet the overall advisory says “critical.”
Take this Secunia advisory for the recent Apple vulnerability disclosure: It has 39 CVEs in it, but one overall rating of “Moderately Critical,” which Secunia defines as:
“Moderately Critical (3 of 5)Typically used for remotely exploitable denial of service vulnerabilities against services like FTP, HTTP, and SMTP, and for vulnerabilities that allow system compromises but require user interaction.This rating is also used for vulnerabilities allowing system compromise on LANs in services like SMB, RPC, NFS, LPD and similar services that are not intended for use over the Internet.“
Pretty broad definition there. In fairness to Secunia, you can drill down on many-but not all-of the individual vulnerabilities and get more granular severity ratings.
It can be hard to pick out these confusions even when you use individual CVE numbers. In this article, Red Hat says:
“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 this flaw had a single CVE identifier.“
It’s easy to see administrators being confused about this, especially if they don’t dig down into the details, and how many people do that?
Everyone wants to provide a big summary severity rating, even the NVD who at least provides granular details behind them, because they believe that the consumers of this information want such ratings. Microsoft also provides some level of detail-not as much as the NVD-to let you determine what your specific exposure is, but the overall ratings loom over the whole process. For home users applying automatic updates, the automatic application of critical updates makes this a very real issue.
The best outcome would be for users to dig into the details, but that isn’t going to happen. Since any attempt to make the data more accessible necessarily involves simplification and value judgements, there’s likely no way to avoid the problems I’ve been discussing. In fact, the only vendor I’m not sympathetic for is Apple, since they choose to chicken out of the whole issue, and they don’t even provide details of their own vulnerabilities. The problem as a whole will continue to plague us; it’s another example of how security is complicated and will remain so.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
For insights on security coverage around the Web, take a look at eWEEK.com Security Center Editor Larry Seltzer’s blog Cheap Hack