[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.10.1402201228140.18439@wniryva.cad.erqung.pbz>
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.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
