Re: Re: CVE Request New-djbdns: dnscache: potential cache poisoning

[P J P <ppandit () redhat com>]

+-- On Wed, 19 Feb 2014, cve-assign () mitre org wrote --+
| traditional sense. Yes, we realize that there's a potentially
| important and potentially simple attack possibility that could have
| been avoided by not choosing djb33. That's not sufficient, however.

  What do you mean not sufficient?

| Also, in this case, some aspects of making a better choice (e.g., with
| sufficiently fast and auditable pseudorandom hashing code) were
| probably not even understood in the research community at the time the
| software was originally written.

  I don't understand. How is it relevant that it was not well understood at 
the time when software was written? It is still an issue. And that argument 
could be true for many other issues. 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

| CVE does, as a secondary form of inclusion, cover vulnerability
| advisories from a vendor who was the original author of a piece of
| software and publishes a change as a required security update. That is
| unlikely here; nobody is anticipating djbdns-1.06.

  Woh..woh..woh!!! Please note that the CVE is requested for 'New-djbdns'. 
New-djbdns is a fully fledged, production quality, fast growing fork of 
the 'djbdns'.

  New-djbdns -> http://pjp.dgplug.org/ndjbdns/

I am the upstream developer and Fedora package maintainer of this project. I 
assure you, version 1.06 is brewing and brewing good. It'll be served when it 
is ready.

I request you to kindly assign a CVE for this and the other issue in 
New-djbdns. Lot of users depend of it.

Thank you.
--
Prasad J Pandit / Red Hat Security Response Team