[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201402201401.s1KE1XIu008770@linus.mitre.org>
Date: Thu, 20 Feb 2014 09:01:33 -0500 (EST)
From: cve-assign@...re.org
To: ppandit@...hat.com
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com
Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> What do you mean not sufficient?
It means that existence of an opportunity for security improvement is
not sufficient for a CVE assignment.
> How is it relevant that it was not well understood at the time when
> software was written? It is still an issue.
CVE is, in the context of this inclusion question, about software
mistakes. Sometimes it is easy to identify a software mistake (e.g.,
off-by-one) and sometimes it is more difficult. If there's a software
deficiency at the layer of algorithm choice, one of the relevant
criteria is the context in which the software was originally
developed. Without that, the entire history of software development
could be reconsidered to assign CVE labels to development choices that
would not have been made today. Typically, for algorithm choices, the
"mistake" versus "not a mistake" question needs to be evaluated in the
environment in which the software was written, not the environment in
which the software is used.
SipHash is a somewhat important advance in computing. There are many,
many products that would be better in some way if SipHash were
introduced. Typically, at the first level, the product would be better
because it would be more resistant to DoS attacks. (We realize that
the New-djbdns case is a little different because the DoS attack
denies intended caching and indirectly facilitates a spoofing attack.
It starts with the DoS against caching, however.) It seems impractical
to assign CVE IDs for all opportunities to use SipHash in all
products, or even for the relatively more important opportunities.
Neither SipHash nor a reasonable equivalent existed when many products
were developed. Because SipHash was unavailable, the product used
alternative development choices that, in practice, may have opened the
product to important threats. However, lack of use of SipHash was not
a "mistake." Almost any product can be improved by addressing more
classes of threats, but this does not establish that a mistake
occurred.
> Like the JSON library example earlier in this thread, or
>
> -> http://www.cvedetails.com/cve/CVE-2012-0770
> -> https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-4885
Those CVEs were based on announcements by vendors who were original
authors of pieces of software. Our first reply already mentioned that
those are an entirely separate case of CVE inclusion.
> Please note that the CVE is requested for 'New-djbdns'. New-djbdns is
> a fully fledged, production quality, fast growing fork
Creation of a fork doesn't change the status of every development
decision from historical to present-day. Otherwise, every "mistake"
versus "not a mistake" question would need to be reevaluated every
time anyone chooses to publish a fork. A very popular reason for
creating a fork is that something is substantially wrong with the
original product. It is common to see ways to make security
improvements, as well as other improvements. Codebase relationships
are, in general, a major complication for CVE. However, at this point,
keeping "algorithm-choice improvement after a fork" outside the scope
of CVE seems to be, on balance, the better alternative.
- --
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (SunOS)
iQEcBAEBAgAGBQJTBgp4AAoJEKllVAevmvmsZJwH/Az3nfxT3gwIKLXneQ8H3aLI
eHX+Z9o09nJn/0tix/B1SbfENZi5uZ/PCvNJfrzS8M7jysfqeyVSgSL5Xm51yFZe
slTmd9/dyzZw63JJwITeNsEBpVCNmsB/ucHrblTeYeYy4CUoB9/iNTlFSdkoj7x3
uhQrI9wt2hsF+dBeFyXOugdeg6PlGp9v8tS1IOhhiOaZiHyZSsff25NyGo4Z+7Hh
7KPOZJ+eEftkJ+w+xqohgJhvch7ivATfDGorEmPFy9VlpsW9PWnPulHSAm+hjC7y
3Z07N10rpQc/IvrTNribMHNK6SR5JbdVg3FsQStgldK4FoQKLrpjcesdapA0qRQ=
=6xI0
-----END PGP SIGNATURE-----
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.
