Slashdot Mirror
Kaminsky's DNS Attack Disclosed, Then Pulled
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak."
Reader Time out contributes a link to coverage on ZDNet as well.
DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).
Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.
DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.
Posted it on: http://rudd-o.com/archives/2008/07/21/the-dns-fiasco/
Rudd-O - http://rudd-o.com/
BGP routes are filtered when they're exchanged between eBGP routers. If you don't filter, you're an idiot. This I agree with.
You're not talking about BGP route filtering, though; you're talking about some kind of reverse path filtering (making sure that a route to the source address exists on the interface that you received the packet from). In practice, you almost never do this on BGP routers, as RPF makes some (somewhat naive) assumptions about the symmetry of Internetwork traffic.
Most people who have some kind of RPF deployed have it on a customer-facing device, as you generally only have one route per customer (and can make assertions about traffic NOT coming via that route, AND traffic COMING via that route.)
That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.
You're doing it wrong.
Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.
An answer may be to use the glue to perform any lookup that can use it as part of that query, but never allow the glue itself to create a cached DNS entry; i.e. to have a life outside that lookup.
Except perhaps caching would be ok, if the cached result can be re-used _only_ when repeating the very same lookup that yielded the glue, the populated additional section.
This approach segments the returned additional section from the rest of the zone (helps constrain the poison to the one subdomain)
Actually, for multihomed sites it's even easier.
Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.
In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render most practical UDP attacks moot.
*ding* You win a cookie. That's exactly what we're saying. There are more ISPs that don't filter traffic than those that do. IP filtering is expensive business at ISP traffic rates. My little Cisco 1760 handles the 5-7Mbps that goes through it rather well. Multiply that by thousands, and that's what ISP's deal with. (Note: a full rate DS3 will swamp a 2851, and that's a pretty damned expensive bit of gear. but it's cheaper than a DS3 PCI(-X/e) card.)
How about to get people to fix their insecure DNS!