Date: Tue, 11 Feb 2014 18:35:58 +0530 (IST) From: P J P <ppandit@...hat.com> To: oss security list <oss-security@...ts.openwall.com> Subject: Re: CVE Request New-djbdns: dnscache: potential cache poisoning Hello Michael, +-- On Tue, 11 Feb 2014, Michael Samuel wrote --+ | 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. 'Frank Denis' is an author of the original link/post. | 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. That's correct. | 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. That is accept requests from predefined networks? djbdns/ndjbdns already does that. Still, that network could be very large. There are also open resolvers. | 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?). No of buckets depend on the cache size. For default cache size of 5MB, it would have about 262144 buckets. | 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. Hmmn..true; DNS is suppose to recycle cached records. But does that mean all DNS implementations are vulnerable to cache poisoning? (given enough efforts) | I'd still recommend switching hash algorithms. That's done. Thank you. -- Prasad J Pandit / Red Hat Security Response Team
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