Multiple DNS implementations vulnerable to cache poisoning
jgreco at ns.sol.net
Wed Jul 9 12:17:53 UTC 2008
> > 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.
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.
More information about the NANOG