[prev in list] [next in list] [prev in thread] [next in thread]
List: oss-security
Subject: Re: [oss-security] CVE Request New-djbdns: dnscache: potential cache poisoning
From: Florian Weimer <fweimer () redhat ! com>
Date: 2014-02-27 16:13:51
Message-ID: 530F643F.9040707 () redhat ! com
[Download RAW message or body]
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
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic