Stop Arguing And Patch Your DNS

Since the CERT announcement yesterday about the new vulnerabilities in DNS, there has been a lot of speculation that what Dan Kaminsky found is old news. Thoman Ptacek from Matasano, in an interview with Nathan McFeters at ZDNet, pretty much dismisses the vulnerability as old news and therefor unimportant. That sentiment is echoed on mailing lists and message boards. But in an e-mail today, Kaminsky confirmed that what he found is something very new. I believe him. Forget the arguments. Go patch your DNS servers. Now.Why do I believe him? Well, mainly because Kaminsky isn't one to run around making grandiose claims he can't back up. But also because the advisory pointed to existing research on the weaknesses in DNS transaction IDs and the problems using fixed or predictable source ports and then the advisory goes on to say "recent additional research into these issues and methods of combining them to conduct improved cache poisoning attacks have yielded extremely effective exploitation techniques." Beyond that, no one is talking about the details until Kaminsky gives a presentation at the Black Hat conference on Aug. 6. That time span allows vendors and customers to receive, test, and deploy a patch -- in this case, a work around -- to make blind DNS cache poisoning more difficult. Presumably, the patches will make UDP source port selection more random than it is today.

Kaminsky is taking it on the chin. But let's say that nothing there is new. Here's Kaminsky's take "But even if there was absolutely nothing new from me, I think everybody wants to see DJB's bugs fixed [DNS forgery], Joe Stewart's bugs fixed [DNS Cache Poisoning -- The Next Generation], and Amit Klein's bugs fixed [BIND 8 DNS Cache Poisoning, BIND 9 DNS Cache Poisoning, Windows DNS Server Cache Poisoning, Microsoft Windows DNS Stub Resolver Cache Poisoning]. These patches will accomplish that. So let's not let speculation get in the way of customers being safe." [I added the report names and links]

We rely on DNS to be authoritative, yet we have very little reason to trust it. A DNS cache poisoning attack combined with a well-implemented man in the middle server is extremely hard for an end user, even a technically savvy one, to detect. All this name resolution is under the hood. Worse, the way SSL is implemented in browsers relies on valid DNS resolution. The only warning you would get from a SSL man-in-the-middle attack is that the server certificate isn't signed by a trusted CA (assuming the signing CA isn't in your certificate store already). The untrusted signed certificate is a clue that something is wrong, but only if you know that something is wrong. Erg.

If this is a known vulnerability that Kaminsky is making noise about, it still doesn't mean it's not important to address. Saying it's a known problem doesn't make it less critical.

So Why The Secrecy?

Kaminsky has said that he worked with vendors for close to a year to make sure that they would be able to supply a patch when the announcement was made. He did that to give organizations time to address the issue before the criminals got a working exploit. Pretty clear-cut reasoning to me. Why do commenter's like Ptacek (who said in the same sentence in the interview above "Dan's DNS credibility is unimpeachable" and "He probably didn't find anything that is more important than the fact that a 16-bit random number isn't secure in the age of OWASP") think that Kaminsky's silence is the result of some nefarious grab at fame and fortune? Hellooooo, isn't this an example of responsible disclosure!

Update 8:00 pm EST on 7/9/2008: Ptacek verified Kaminsky's claim by phone.

Well, here's why. The suggested fix is to randomize the UDP source ports the DNS server uses to make DNS queries to other DNS servers. For example, an Infoblox DNS server always uses UDP port 32772 as the source port, and to poison DNS, all you need to do is guess the transaction ID. That doesn't mean that the problem Kaminsky found is with UDP source port randomization. The suggestion, again clearly explained in the advisory and by Kaminsky in his blog, is a work-around to make guessing more difficult. Thinking UDP source port randomization is the crux of the problem is ipso without the facto.

Let me close with one more Kaminsky gem: