Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 11 Feb 2014 18:35:58 +0530 (IST)
From: P J P <>
To: oss security list <>
Subject: Re: CVE Request New-djbdns: dnscache: potential cache

   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

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ