Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Feb 2014 09:01:33 -0500 (EST)
Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning

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

> Like the JSON library example earlier in this thread, or
>  ->
>  ->

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 ]
Version: GnuPG v1.4.14 (SunOS)


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.