North American Network Operators Group|
Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical
Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?
On Thu, Jul 24, 2008 at 9:35 AM, Joe Greco <jgreco@xxxxxxxxxx> wrote: > Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is > groundbreaking, except that threats discussed long ago have become more > practical due to the growth of network and processing speeds, which was > a hazard that ... was actually ALSO predicted. Joe, Early attacks were based on returning out-of-scope data in the Additional section of the response. This was an implementation error in the servers: they should never have accepted out of scope data. Later attacks were based on forging responses to a query. The resolver sends a query packet and the attacker has a few tens of milliseconds in which to throw maybe a few tens of guesses about correct ID at the resolver before the real answer arrives from the the real server. These were mitigated because: a. You had maybe a 1 in 1000 chance of guessing right during the window of opportunity. b. If you guessed wrong, you had to wait until the TTL expired to try again, maybe as much as 24 hours later. So, it could take months or years to poison a resolver just once, far below the patience threshold for your run-of-the-mill script kiddie. What's new about this attack is that it removes mitigator B. You can guess again and again, back to back, until you hit that 1 in 1000. Paul tells us this can happen in about 11 seconds, well inside the tolerance of your normal script kiddie and long before you'll notice the log messages about invalid responses. Anyway, it shouldn't be hard to convert this from a poisoning vulnerability to a less troubling DOS vulnerability by rejecting responses for a particular query (even if valid) when received near a bad-id response. From there it just takes some iterative improvements to mitigate the DOS. In the mean time, randomizing the query port makes the attack more than four orders of magnitude less effective and causes it to require more than four orders of magnitude of additional resources on the attacker's part. Regards, Bill Herrin -- William D. Herrin ................ herrin@xxxxxxxxxxxx bill@xxxxxxxxx 3005 Crane Dr. ...................... Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004