[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
