Bug 234344

Summary:	net-dns/bind*: New BIND already vulnerable to cache poissoning
Product:	Gentoo Security	Reporter:	Emanuele Gentili <gentili>
Component:	Vulnerabilities	Assignee:	Gentoo Security <security>
Status:	RESOLVED INVALID
Severity:	major	CC:	bind+disabled
Priority:	High
Version:	unspecified
Hardware:	All
OS:	Linux
URL:	http://tservice.net.ru/~s0mbre/blog/devel/networking/dns/2008_08_08.html
Whiteboard:
Package list:		Runtime testing required:	---

Description Emanuele Gentili 2008-08-10 03:43:14 UTC

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/

Comment 1 Robert Buchholz (RETIRED) gentoo-dev

2008-08-14 10:44:18 UTC

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?

Comment 2 Raphael Marichez (Falco) (RETIRED) gentoo-dev

2008-08-18 15:35:01 UTC

(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.