Multiple DNS implementations vulnerable to cache poisoning

Jimmy Hess mysidia at gmail.com
Tue Jul 8 21:22:23 CDT 2008


Christian Koch wrote:
> 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.

> On Tue, Jul 8, 2008 at 8:20 PM, Owen DeLong <owen at delong.com> wrote:
>   
>> The tool, unfortunately, only goes after the server it thinks you are using
>> to
>> recurse from the client where you're running your browser.
>>     
The very nature of the tool  (remote probe by an outside server)  also 
makes it impossible for it you to probe
intermediary DNS servers.

For example, you might resolve using vulnerable recursive server that 
forwards all queries to a 'safe'
recursive server.

The TXIDs generated by the 'vulnerable'  server are never seen by the 
remote web server.

>> This makes it hard to test servers being used in production environments
>> without GUIs.  The tool is not Lynx compatible.
>>
>> Owen
>>     

--
-J




More information about the NANOG mailing list