Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 20 Feb 2014 12:44:25 +0530 (IST)
From: P J P <>
cc: oss security list <>
Subject: Re: CVE request New-djbdns: dnscache: possible DoS

+-- On Wed, 19 Feb 2014, 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 

  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 

| 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

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ