Date: Thu, 27 Feb 2014 17:13:51 +0100 From: Florian Weimer <fweimer@...hat.com> To: oss-security@...ts.openwall.com Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning On 02/11/2014 07:54 AM, P J P wrote: > Hi, > > +-- On Mon, 10 Feb 2014, P J P wrote --+ > | I'll check with the upstream author for more clarification. > > Upstream author's reply: > > > On Tuesday, 11 February 2014 4:28 AM, Frank Denis wrote: > > > > The shorter the TTL of a record is, the easier a cache can be poisoned. > > It is when a record is NOT cached that spoofed authoritative replies > > can be sent and get a chance to reach the resolver before the > > legitimate one. > > > > As soon as a valid response is received, dnscache invalidates the state, > > discarding further responses, even if these are valid. Hannes Sowa pointed out to me that djbdns deliberately does not prevent cache eviction by crafted queries/responses: "dnscache doesn't discriminate against additional records. Valid records are accepted whether they're additional records in one packet or answer records in the next; timing doesn't affect the semantics." <http://cr.yp.to/djbdns/notes.html> The issue raised in this thread only allows to carry out "attacks" that are also possible by relying on a documented design decision, so it's doubtful this qualifies as a security bug. (Note that most resolver implementations also lack protection against cache eviction. Several vendors reviewed this topic in 2008 and deemed it too difficult to implement as a general security feature.) -- Florian Weimer / Red Hat Product Security 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.