[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <530F643F.9040707@redhat.com>
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.
