Date: Wed, 12 Nov 2014 21:33:30 +0100 From: Florian Weimer <fw@...eb.enyo.de> To: oss-security@...ts.openwall.com Subject: Additional authority files I noticed that for two high-profile bugs this year, we hit a limitation with the CVE authority file: We had no proper way to refer to the prefix/suffix patch for bash because it does not address a specific vulnerability. All the individual vulnerabilities received separate CVE entries, and none was left we could associate with the prefix/suffix patch. For POODLE, we did not have CVE identifiers associated for the fallback behavior because it was not considered a vulnerability. We do not have ways to refer to specific client behavioral changes (even where this is appropriate, such as sending TLS_FALLBACK_SCSV during fallback). We did not have a way to refer to TLS_FALLBACK_SCSV support in server code, either. (In the POODLE case, we also saw that putting the year into the name can be quite misleading—the vulnerability which was considered CVE-worthy was disclosed around 2002, discussed in an OpenSSL advisory in 2003, and should have been associated with that timeframe, and not the year 2014.) Recent discussions about issues brought to this list suggest to me that the reluctance to label things as a vulnerability continues. (I won't speculate about the reasons.) Unfortunately, it happens too often that people operate systems well outside their documented security margins—which allows vendors disclaim any security vulnerability, but these misguided practices still can cause operational issues which cannot be ignored, require mitigations, and discussions would benefit from the clarity only an authority file can bring. Consequently, I wonder if we need separate authority files for Potentially Unwanted Behaviors (comparable to Potentually Unwanted Applications, avoiding the vulnerability stigma just as PUAs avoid the “malware” label) and Recommended Behavioral Changes (same thing, but on the fixes side). This would help us to make sure we talk about the same things, just as CVE does now for vulnerabilities. Thoughts?
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.