Re: CVE Request New-djbdns: dnscache: potential cache poisoning

[Florian Weimer <fweimer () redhat com>]

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