[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CACYkhxg4r2ju6V4C4az+MOXGXrBWukC32M6so0Bfe6DfUh42mA@mail.gmail.com>
Date: Fri, 21 Feb 2014 10:59:40 +1100
From: Michael Samuel <mik@...net.net>
To: oss-security@...ts.openwall.com
Subject: Re: Re: CVE Request New-djbdns: dnscache: potential
cache poisoning
On 21 February 2014 03:21, <cve-assign@...re.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
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.
