|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Paul Vixie: Re: [dns-operations] DNS issue accidentally leaked?
> downplay this all you want, we can infect a name server in 11 seconds now, > which was never true before. i've been tracking this area since 1995. don't > try to tell me, or anybody, that dan's work isn't absolutely groundbreaking. > > i am sick and bloody tired of hearing from the people who aren't impressed. Well, Paul, I'm not *too* impressed, and so far, I'm not seeing what is groundbreaking, except that threats discussed long ago have become more practical due to the growth of network and processing speeds, which was a hazard that ... was actually ALSO predicted. And you know what? I'll give you the *NEXT* evolutionary steps, which could make you want to cry. If the old code system could result in an infected name server in 11 seconds, this "fix" looks to me to be at best a dangerous and risky exercise at merely reducing the odds. Some criminal enterprise will figure out that you've only reduced the odds to 1/64000 of what they were, but the facts are that if you can redirect some major ISP's resolver to punt www.chase.com or www.citibank.com at your $evil server, and you have large botnets on non-BCP38 networks, you can be pumping out large numbers of answers at the ISP's server without a major commitment in bandwidth locally... and sooner or later, you'll still get a hit. You don't need to win in 11 secs, or even frequently. It can be "jackpot" monthly and you still win. Which is half the problem here. Bandwidth is cheap, and DNS packets are essentially not getting any bigger, so back in the day, maybe this wasn't practical over a 56k or T1 line, but now it is trivial to find a colo with no BCP38 and a gigabit into the Internet. The flip side is all those nice multicore CPU's mean that systems aren't flooded by the responses, and they are instead successfully sorting through all the forged responses, which may work in the attacker's advantage (doh!) This problem really is not practically solvable through the technique that has been applied. Give it another few years, and we'll be to the point where both the QID *and* the source port are simply flooded, and it only takes 11 seconds, thanks to the wonder of ever-faster networks and servers. Whee, ain't progress wonderful. Worse, this patch could be seen as *encouraging* the flooding of DNS servers with fake responses, and this is particularly worrying, since some servers might have trouble with this. So, if we want to continue to ignore proper deployment of DNSSEC or equivalent, there are some things we can do: * Detect and alarm on cache overwrite attempts (kind of a meta-RFC 2181 thing). This could be problematic for environments without consistent DNS data (and yes, I know your opinion of that). * Detect and alarm on mismatched QID attacks (probably at some low threshold level). But the problem is, even detected and alerted, what do you do? Alarming might be handy for the large consumer ISP's, but isn't going to be all that helpful for the universities or fortune 500's that don't have 24/7 staff sitting on top of the nameserver deployment. So, look at other options: * Widen the query space by using multiple IP addresses as source. This, of course, has all the problems with NAT gw's that the port solution did, except worse. This makes using your ISP's "properly designed" resolver even more attractive, rather than running a local recurser on your company's /28 of public IP space, but has the unintended consequence of making those ISP recursers even more valuable targets. Makes you wish for wide deployment of IPv6, eh. > every time some blogger says "this isn't new", another five universities > and ten fortune 500 companies and three ISP's all decide not to patch. > that means we'll have to wait for them to be actively exploited before they > will understand the nature of the emergency. While I applaud the reduction in the attack success rate that the recent patch results in, I am going to take a moment to be critical, and note that I feel you (and the other vendors) squandered a fantastic chance. Just like the Boy Who Cried Wolf, you have a limited number of times that you can cry "vulnerability" and have people mostly all stand up and pay attention in the way that they did. Hardly the first (but possibly one of the most noteworthy), RIPE called for signing of the root zone a year ago. I note with some annoyance that this would have been a great opportunity for someone with a lot of DNS credibility to stand up and say "we need the root signed NOW," and to force the issue. This would have been a lot of work, certainly, but a lot of *worthwhile* work, at various levels. The end result would have been a secure DNS system for those who chose to upgrade and update appropriately. Instead, it looks to me as though the opportunity is past, people are falsely led to believe that their band-aid-patched servers are now "not vulnerable" (oh, I love that term, since it isn't really true!) and the next time we need to cry "fire," fewer people will be interested in changing. The only real fix I see is to deploy DNSSEC. I've tried to keep this message bearably short, so please forgive me if I've glossed over anything or omitted anything. ... JG -- Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net "We call it the 'one bite at the apple' rule. Give me one chance [and] then I won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN) With 24 million small businesses in the US alone, that's way too many apples.
|