Date: Thu, 20 Feb 2014 12:44:25 +0530 (IST) From: P J P <ppandit@...hat.com> To: cve-assign@...re.org cc: oss security list <oss-security@...ts.openwall.com> Subject: Re: CVE request New-djbdns: dnscache: possible DoS +-- On Wed, 19 Feb 2014, cve-assign@...re.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
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ