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

[Michael Samuel <mik () miknet net>]

On 21 February 2014 03:21, <cve-assign () mitre org> wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> > So, if original author says it's a flaw then it's a flaw, otherwise not?
>
> Otherwise MITRE attempts to use the best available information in
> deciding whether "security improvement" is a better categorization.
> Across all types of products and problems, the original author is
> generally allowed to admit that they made a mistake when writing the
> code in a certain way.


This is flawed reasoning.  The question is: if there is a patch for software
that addresses an attack, will users expect to get this pushed out to them
via their distribution outside of the release cycle?

In this case, the clear answer is yes.

> So now SipHash is 'the only' way to avoid hash collision ever?

> At present, introducing SipHash is a type of patch that's very likely
> to be considered when a software maintainer is responding to
> hash-collision problems. Certainly other patch approaches are
> possible. Not all code originated with an implicit functional
> specification that the code would do a good job at resisting all types
> of intentional hash-collision attacks. So, in general, when a
> description of a new attack is published, any resulting patches can be
> considered security improvements.


This is not true. When a new attack is published, patches are made for
software that are vulnerable to the attack. This is what CVE numbers
track.

Also, this isn't a standard unbalanced hashtable CPU DoS flaw - this is
causing fundamental changes in the software's behaviour based on
hashtable collisions.

Regards,
  Michael