Comments on: DNS Vulnerability; The Other Part of that Partial Disclosure http://ddos.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/ A weblog dedicated to educating the community on security threats that matter Mon, 07 May 2012 13:07:22 +0000 hourly 1 http://wordpress.org/?v= By: Michael N. Dundas » DNS Poisoning attack discovered by Dan Kaminsky http://ddos.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/comment-page-1/#comment-241938 Michael N. Dundas » DNS Poisoning attack discovered by Dan Kaminsky Thu, 17 Dec 2009 17:51:09 +0000 http://asert.arbornetworks.com/?p=270#comment-241938 [...] just trust us to protect you and do the right thing. A good article on the chronology of events is here. The reason for not telling the public was that it was going to be presented at Blackhat in a [...] [...] just trust us to protect you and do the right thing. A good article on the chronology of events is here. The reason for not telling the public was that it was going to be presented at Blackhat in a [...]

]]> By: Jon Oberheide http://ddos.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/comment-page-1/#comment-147014 Jon Oberheide Wed, 23 Jul 2008 20:59:17 +0000 http://asert.arbornetworks.com/?p=270#comment-147014 Danny, I've seen several people making the argument similar to your point: "Reverse engineers are encouraged to have a gander, speculation is good", which doesn't mesh with what Dan actually communicated with the public. What Dan explicitly encouraged was further investigation and scrutiny of DNS (which is a good thing). What he explicitly discouraged was public speculation of the vulnerability (which of course is an arguable point). There was certainly no higher authority enforcing Dan's requests, so it was up to the opinion of each and every researcher to judge his requests and guide their own actions. But saying that Dan encouraged speculation is inaccurate. Also, the attack doesn't rely on the birthday paradox. In fact, it's even more simple. If you can play a game with a low probability of winning a large number of times, you can achieve a high probability of eventually winning one of the games. Since we can request an "unlimited" number of non-existent RRs, each with a low probability X/(2^16) of succeeding (where X is the number of TXIDs we're able to successfully beat the authoritative server with in the race), we will eventually win the game and poison the cache by slipping in the malicious glue NS RR. Regards, Jon Oberheide Danny,

I’ve seen several people making the argument similar to your point: “Reverse engineers are encouraged to have a gander, speculation is good”, which doesn’t mesh with what Dan actually communicated with the public. What Dan explicitly encouraged was further investigation and scrutiny of DNS (which is a good thing). What he explicitly discouraged was public speculation of the vulnerability (which of course is an arguable point). There was certainly no higher authority enforcing Dan’s requests, so it was up to the opinion of each and every researcher to judge his requests and guide their own actions. But saying that Dan encouraged speculation is inaccurate.

Also, the attack doesn’t rely on the birthday paradox. In fact, it’s even more simple. If you can play a game with a low probability of winning a large number of times, you can achieve a high probability of eventually winning one of the games. Since we can request an “unlimited” number of non-existent RRs, each with a low probability X/(2^16) of succeeding (where X is the number of TXIDs we’re able to successfully beat the authoritative server with in the race), we will eventually win the game and poison the cache by slipping in the malicious glue NS RR.

Regards,
Jon Oberheide

]]> By: D2 http://ddos.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/comment-page-1/#comment-146790 D2 Wed, 23 Jul 2008 04:54:53 +0000 http://asert.arbornetworks.com/?p=270#comment-146790 For some reason my commentary on doxpara.com and matasano.com blogs including twitter for Security Twits has largely gone unnoticed. Kudos for bringing up RFC2827 again as things like spoof protection, uRPF, FW-extensions, tracking UDP-state, HIPS looking at floods from single SRC IP would all help to address attacks on ISPs and Enterprises. Essentially one must spoof the authoratative NS SRC IP for this to work. Sure you have to initiate the lookup via iframes/image tags/SPAM or compromised hosts to start the race in the first place, but with some form of 'state' and good filtering this shouldn't be such an issue. Network configs can buy time to addess patching.... TIME is still the issue, both the start time and the response time... Maybe I am missing something. Maybe not. For some reason my commentary on doxpara.com and matasano.com blogs including twitter for Security Twits has largely gone unnoticed. Kudos for bringing up RFC2827 again as things like spoof protection, uRPF, FW-extensions, tracking UDP-state, HIPS looking at floods from single SRC IP would all help to address attacks on ISPs and Enterprises. Essentially one must spoof the authoratative NS SRC IP for this to work.

Sure you have to initiate the lookup via iframes/image tags/SPAM or compromised hosts to start the race in the first place, but with some form of ‘state’ and good filtering this shouldn’t be such an issue. Network configs can buy time to addess patching…. TIME is still the issue, both the start time and the response time…

Maybe I am missing something. Maybe not.

]]> By: Average User http://ddos.arbornetworks.com/2008/07/dns-vulnerability-the-other-part-of-that-partial-disclosure/comment-page-1/#comment-146784 Average User Wed, 23 Jul 2008 04:04:50 +0000 http://asert.arbornetworks.com/?p=270#comment-146784 If a cautious end user avoids using DNS for critical sites by going to http:\\[ip address of Big Bank Inc] rather than www.BigBankInc.com, then said user has no worries, correct? If a cautious end user avoids using DNS for critical sites by going to http:\\[ip address of Big Bank Inc] rather than http://www.BigBankInc.com, then said user has no worries, correct?

]]>