Date: Tue, 11 Feb 2014 22:28:35 +1100 From: Michael Samuel <mik@...net.net> To: oss-security@...ts.openwall.com Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning On 11 February 2014 17:54, P J P <ppandit@...hat.com> wrote: > 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. > This response doesn't address the original claim. The author of the original link made the (probably true) claim that requests could be made to authoritative sources (records under the control of the attacker) which would deliberately collide with results for some other domain such as .com. Since each bucket has a limit of 100 records, this would make it easier to push a record from the cache, giving the attacker another chance at spoofing a reply a little bit sooner. Each time this happened, the attacker would have just under 1 in 2^32 chance of succeeding. The simplest strategy for this would be to constantly send replies to a specific port with a specific ID, and waiting for the server to randomly use this combination, in which case the attacker would surely beat the server. The security flaw is in the DNS protocol, and (apart from protocol upgrade fantasies) the only practical way to mitigate this is to have a pool of IP addresses to initiate recursive requests from. Using siphash would make this attack slightly harder, but a large number of random names would presumably have a similar effect for only slightly more traffic (how many buckets are there?). In short, the hashtable is not a DNS cache poisoning protection mechanism, DNS cache is supposed to expire or be pushed out by "hotter" records, so I'd say it's not a vulnerability. I'd still recommend switching hash algorithms. Regards, Michael
Powered by blists - more mailing lists
Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.
Powered by Openwall GNU/*/Linux - Powered by OpenVZ