[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <52F89EEA.40106@redhat.com>
Date: Mon, 10 Feb 2014 10:42:02 +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/10/2014 08:34 AM, P J P wrote:
> ===
> ...
> By exploiting a hash table collision, an attacker has no way to trigger
> a DoS, but he can actually do something way more interesting: force the
> resolver to send the same query for the same TLD, over and over again,
> always to the same set of servers, no matter what the intended TTL is
> and no matter what the cache size is.
>
> And suddenly, poisoning dnscache with a malicious TLD much, much, much
> easier and faster.
> ===
>
> Not sure if it qualifies for a CVE; the excerpt above deems it a likely
> candidate.
How it is possible to poison the cache if the response is not cached?
If dnscache updates the cache with additional or authoritative data,
overriding existing data (as most resolvers do), then it is possible to
do so without relying on the implementation anomaly quoted above.
In short, I'm not convinced at all that the alleged security implication
exist.
(This message shall not be interpreted as an endorsement of dnscache.)
--
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.
