More On The DNS Vulnerability
Okay- it’s been a crazy 36 hours since Dan Kaminsky released his information on the massive multivendor patch and DNS issue. I want to give a little background on how I’ve been involved (for full disclosure) as well as some additional aspects of this. If you hate long stories, the short version is he just walked me through the details, this is a very big deal, and you need to patch immediately.
Dan contacted me about a week or so ago to help get the word out to the CIO-level audience. As an analyst, that’s a group I have more access to. I was involved with the initial press conference and analyst briefings, and helped write the executive overview to put the issue in non-geek terms.
At the time he just gave me the information that was later made public. I’ve known Dan for a few years now and trust him, so I didn’t push as deeply as I would with someone I don’t have that relationship with. Thus, as the comments and other blogs dropped into a maelstrom of discontent, I didn’t have anything significant to add.
Dan realized he underestimated the response of the security community and decided to let me, Ptacek, Dino, and someone else I won’t mention into the fold.
Here’s the deal- Dan has the goods. More goods than I expected. Dino and Ptacek agree. Tom just issued a public retraction/apology. This is absolutely one of the most exceptional research projects I’ve seen. Dan’s reputation will emerge more than intact, although he will still have some black eyes for not disclosing until Black Hat.
Here’s what you need to know:
- You must patch your name servers as soon as possible. This is real, it’s probably not what you’re thinking. It’s a really good exploit (which is bad news for us).
- Ignore the “Important” rating from Microsoft, and other non-critical ratings. You have to keep in mind that for many of those organizations nothing short of remote code execution without authentication will result in a critical rating. That’s how the systems are built.
- Dan screwed up some of his handling of this, and I’m part of that screwup since I set my cynical analyst hat aside and ran totally on trust and reputation. Now that I know more, I stand behind my reaction and statements, but that’s a bad habit for me to get into.
- This still isn’t the end of the world, but it’s serious enough you should break your patch cycle (if you have one) on name servers to get them fixed. Then start rolling out to the rest of your infrastructure.
- CERT is updating their advisory on an ongoing basis. It’s located here.
Next time something like this happens I’ll push for full details sooner, but Dan is justified in limiting exposure of this. His Black Hat talk will absolutely rock this year.








windexh8er Jul 9
Well… On one hand I’m pissed I have to wait 30 days. On the other I’m glad that Dan will not get thrown under the bus / into the fire because of the said legitimacy. *tick* *tick* *tick*
Fifth.Sentinel Jul 9
Since you said you helped Dan on exec summary for the vulnerability. There is a double “traffic” at end of 2nd para in the document.
Phil Jul 10
Patch your nameservers. That’s not enough in itself.
You’ll need to check your nameserver config too. If using BIND, get rid of any
query-source port 53;
query-source-v6 port 53;
kind of lines in named.conf and named.caching-nameserver.conf
No point in using a patched daemon if your config forces it to use a single source port.
Phil Jul 10
RedHat have updated their 5.x packages and their advisory:
“[Updated 10th July 2008]
We have updated the Enterprise Linux 5 packages in this advisory. The default and sample caching-nameserver configuration files have been updated so that they do not specify a fixed query-source port. Administrators wishing to take advantage of randomized UDP source ports should check their
configuration file to ensure they have not specified fixed query-source ports.”
Yay!
John Jul 10
My home ISP’s DNS checks as vulnerable at doxpara.com. Is there anything I can do at my router or on my computers to protect myself?
rmogull Jul 10
Yes- just go use OpenDNS.
Fifth.Sentinel Jul 14
Given the noise over this vulnerability I don’t see the biggest threat to be from service providers and enterprises. In fact, given the great American legal tradition (thank god I am not American), I am sure that any service interruption in the future due to exploitation will lead to our friendly lawyers getting their Christmas bonus due to class actions etc etc etc… Therefore I think most service providers will patch themselves.
Its the home users which the bot herders, spammers etc will go after once the full exploit is public. While people like Microsoft may have released patches that will protect the mom and pop users due to automatic updates. What do we do about the same users broadband routers/modems? How much of a risk are these routers/modems to the vulnerability if they are acting as the local resolving DNS for home PCs? It is hard enough to have these home users to keep their OS and AV up to date. Realistically, what is the likelihood that they will realize they need to update the firmware on the router/modem to protect themselves also?