New BIND version is vulnerable to cache poissoning BIND used fully randomized source port range, i.e. around 64000 ports. Two attacking servers, connected to the attacked one via GigE link, were used, each one attacked 1-2 ports with full ID range. Usually attacking server is able to send about 40-50 thousands fake replies before remote server returns the correct one, so if port was matched probability of the successful poisoning is more than 60%. Attack took about half of the day, i.e. a bit less than 10 hours. So, if you have a GigE lan, any trojaned machine can poison your DNS during one night. Reproducible: Always Steps to Reproduce: exploit: http://tservice.net.ru/~s0mbre/archive/dns/
Detecting brute force attacks from inside the daemon with high enough reliability would require techniques as described in this article: http://blog.netherlabs.nl/articles/2008/08/05/calculating-the-chance-of-spoofing-an-agile-source-port-randomised-resolver Is there a statement by ISC (BIND upstream) whether they intend to do so?
(In reply to comment #1) > > Is there a statement by ISC (BIND upstream) whether they intend to do so? > No, they will not do anything. This issue is invalid. This URL is not serious, the only goal of its author is to receive media coverage. Mitre has not assigned any CVE id. What he is talking about is entirely linked to the DNS protocol itself. That URL uses nothing new, and is not related to Kaminsky's attack (which relies on the ability to force a caching resolver to generate many requests). Kaminsky does not use Gigabit links, and previous BIND/DNS randomness issues did not use Gigabit links either. That weakness is limited to the LAN, and is an architecture issue. DNS can't do anything against that without a cryptographic support like DNSSEC. Since this attack can only realisticly be performed from the local network; - put your caching resolver in a DMZ, if you do not trust your LAN users - implement rate limiting on your DMZ with your best firewall box, or network monitoring. This kind of attack mostly behaves like a (D)DoS.
