Slashdot Mirror

← Back to Stories (view on slashdot.org)

BIND Still Susceptible To DNS Cache Poisoning

Posted by Soulskill on from the still-in-a-bind dept.

An anonymous reader writes "John Markoff of the NYTimes writes about a Russian hacker, Evgeniy Polyakov, who has successfully poisoned the latest, patched BIND with randomized ports. Originally, the randomized ports were never supposed to completely solve the problem, but just make it harder to do. It was thought that with port randomization, it would take roughly a week to get a hit. Using his own exploit code, two desktop computers and a GigE link, Polyakov reduced the time to 10 hours."

3 of 146 comments (clear)

  1. This isn't a BIND problem. by CustomDesigned · · Score: 5, Informative

    This has nothing to do with BIND vulnerabilities. DJdns, or whatever you feel is more secure, has exactly the same problem. It is a protocol weakness. The article mentions BIND only because it is the reference implementation for DNS.

    The most interesting idea I've seen is to use IPv6 for DNS. The oldest idea is to start using DNSSEC.

    1. Re:This isn't a BIND problem. by Anonymous Coward · · Score: 5, Informative

      The basis of the attack is to include "extra" information in a forged response to a query for a non-existent host. Bind trusts that extra information and other DNS servers only pay attention to that information if it falls under certain strict rules.

      I ask for aaaae3fcg.bankofamerica.com and also send 100,000 responses to that query to that same recursive DNS server, that all say something to the effect of "a record aaae3fcg.bankofamerica.com = bah, also look to 666.666.666.666 for anything else related to bankofamerica.com. Oh, and cache this until the sun goes dark"

      Nobody asks Bind to believe the part about THE REST OF THE WHOLE BLOODY DOMAIN in the response for a single record in the domain. No other servers cache that information.

      That bind also used non-random ports made it a 5 minute attack over a fast link, instead of a 10 hour attack. That in the past bind used bad random numbers for the transaction ID made it a 30 packet attack...

      Who's the fanboy now?

  2. DJB's take . . . by geniusj · · Score: 5, Informative

    For those that haven't seen it, djb threw up some information regarding this problem and various options a few years ago.

    http://cr.yp.to/djbdns/forgery.html