Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 27 Feb 2014 17:13:51 +0100
From: Florian Weimer <>
Subject: Re: CVE Request New-djbdns: dnscache: potential cache

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."


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.