![nanog logo](/images/nanog-logo.png)
nanog mailing list archives
Re: Multiple DNS implementations vulnerable to cache poisoning
From: Joe Greco <jgreco () ns sol net>
Date: Wed, 9 Jul 2008 07:17:53 -0500 (CDT)
surely the tool is not focused at a dns operator/admin audience..I suspect the tool's form might partly be meant to obscure exactly what patterns it is looking for. Kind of how one might release a vulnerability checker in binary form (but with source code intentionally witheld) 5 query samples would not seem to be a sufficient number to compute the probability that the TXIDs and source ports are both independent and random, with stringent confidence intervals, and that there is no sequence predictability (due to use of a PRNG)... More exhaustive tool would operate on tcpdump output or run live with pcap, gather samples of sequences of TXIDs, port numbers, timestamps. And perform tests for independency between TXID and port number, timestamp, and some statistical tests for randomness.
Since it appears as though a significant part of the solution is tied to upgrading to new code, which implements better PRNG *and* random source ports, it seems that one indicator for vulnerability is simply the reuse of a source port number, which should be trivial to identify without any concern for having to look for "patterns" within the PRNG-generated TXID. You do not necessarily need to be able to verify that something is NOT vulnerable in order to detect vulnerability. Your answers will only be "is vulnerable" and "might be vulnerable" of course, but that's useful all by itself. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
Current thread:
- Re: Multiple DNS implementations vulnerable to cache poisoning, (continued)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jimmy Hess (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jean-François Mezei (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Chris Adams (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Michael C. Toren (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jean-François Mezei (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jay R. Ashworth (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Simon Waters (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jay R. Ashworth (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Tuc at T-B-O-H.NET (Jul 11)
- Re: Multiple DNS implementations vulnerable to cache poisoning Brian Keefer (Jul 25)
- Re: Multiple DNS implementations vulnerable to cache poisoning Joe Greco (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Lynda (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jeffrey Ollie (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Jay R. Ashworth (Jul 08)
- Re: Multiple DNS implementations vulnerable to cache poisoning Christopher Morrow (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Steven M. Bellovin (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Christopher Morrow (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Steven M. Bellovin (Jul 09)
- RE: Multiple DNS implementations vulnerable to cache poisoning Martin Hannigan (Jul 09)
- Re: Multiple DNS implementations vulnerable to cache poisoning Sean Donelan (Jul 09)