Re: CVE request New-djbdns: dnscache: possible DoS

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

+-- On Wed, 19 Feb 2014, cve-assign () mitre org wrote --+
| Changing the TCP read approach can be considered a performance
| improvement (and, somewhat marginally, a security improvement), with
| no CVE assignment. The commit mentions "making slight gain in
| performance" and "could also lead to potential denial of service."

  Yes, slight gain because it reduces 'read(2)' calls. And potential DoS 
because:

  On Tuesday, 11 February 2014 5:22 AM, Frank Denis wrote:
  >
  > ...
  > The spike of CPU between the first query for a name/type and
  > its resolution is an old standing bug.
  >
  > ... We spawn dnscache threads to balance the load on all CPU cores.
  > And when running the PoC, the whole system starts crawling because
  > of the high number of system calls.

'Frank Denis' is the author of the PoC and earlier article about the SipHash 
issue.


| The original implementation might have chosen its approach for 
| design-for-auditability reasons, i.e., it may not have been a "mistake" at 
| all. It seems impractical to assign CVE IDs to all opportunities to speed up 
| the processing of untrusted input in all products. The situation would be 
| different if it were clearly a logic error in the code, e.g., processing the 
| first byte once, the second byte four times, the third byte nine times, etc.

  I don't understand why is it relevant whether it's a genuine mistake or 
logic error or an intentional bug?

  The behaviour opens room for a practical DoS attack. That is a security 
issue. There is a PoC available for it. There is fix available for it, which 
has been applied. Why not a CVE?

--
Prasad J Pandit / Red Hat Security Response Team