[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <87sihocg6d.fsf@mid.deneb.enyo.de>
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.
