oss-sec mailing list archives
Re: CVE Request New-djbdns: dnscache: potential cache poisoning
From: Michael Samuel <mik () miknet net>
Date: Tue, 11 Feb 2014 22:28:35 +1100
On 11 February 2014 17:54, P J P <ppandit () redhat 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
Current thread:
- CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 09)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Florian Weimer (Feb 10)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 10)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 10)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Michael Samuel (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Michael Samuel (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 17)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Michael Samuel (Feb 17)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 18)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 10)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Florian Weimer (Feb 10)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Michael Samuel (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning P J P (Feb 11)
- Re: CVE Request New-djbdns: dnscache: potential cache poisoning Florian Weimer (Feb 27)