Date: Wed, 12 Nov 2014 20:56:35 +0000 From: "Radzykewycz, T (Radzy)" <radzy@...driver.com> To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com> Subject: RE: [security-vendor] Additional authority files > (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.) In my opinion, the year should be the year that the CVE number is assigned. This won't change and is not subject to revision after new information comes to light. The time that the issue was first noticed and/or discussed seems less likely to be stable. If someone reports a bug in 2015, knowing that it was discussed in 2014 but not knowing that it was discussed in 2009, then a 2014 year might be assigned to it. But later on, people would assume that it was first discussed in 2014 and not known until then. So the net result would be some desire to re-name some vulnerabilities as well as overall confusion. ________________________________________ From: Florian Weimer [fw@...eb.enyo.de] Sent: Wednesday, November 12, 2014 12:33 PM To: oss-security@...ts.openwall.com Subject: [security-vendor] [oss-security] 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.