Some thoughts on the recent DNS vulnerability
Posted by bert hubert Wed, 09 Jul 2008 19:31:00 GMT
Yesterday it was announced that there is an unspecified but major DNS vulnerability, and that Microsoft, Nominum and ISC had fixes available.
It is amusing to note that this has been hailed as a major feat of cooperation, with the vulnerable parties spinned as being part of secret industry cabal that has just saved the world from very bad things.
To say the least, I find this a funny way of presenting things! The vulnerability is still not public, but the secret cabal shared it with me. Perhaps it is fair to say I am part of the cabal - I nearly traveled to the secret meeting at the Microsoft campus, but the imminent birth of my son made me decide not to go.
The DNS vulnerability that has been presented yesterday is indeed a very serious problem, and I am glad steps are now taken to fix the broken software that was vulnerable. Dan Kaminksy is to be praised for discovering the issue and coordinating the release.
However - the parties involved aren’t to be lauded for their current fix. Far from it. It has been known since 1999 that all nameserver implementations were vulnerable for issues like the one we are facing now. In 1999, Dan J. Bernstein released his nameserver (djbdns), which already contained the countermeasures being rushed into service now. Let me repeat this. Wise people already saw this one coming 9 years ago, and had a fix in place.
In 2006 when my own resolving nameserver entered the scene, I decided to use the same security strategy as implemented in djbdns (it is always better to steal a great idea than to think up a mediocre one!). Some time after that, I realised none of the other nameservers had chosen to do so, and I embarked on an effort to move the IETF DNS-EXT working group to standardise and thus mandate this high security behaviour.
This didn’t really go anywhere, but some months ago I noticed particularly strenuous resistance in the standardisation of the so called ‘forgery resilience draft’, and after some prodding it became clear it was felt my draft was in danger of drawing attention to the then unannounced DNS vulnerability, and that it were best if we’d all shut up about it for a few months, perhaps until July 2008 until all the vendors would have had time to get their act together.
And now we’ve seen the release, and it is being hailed as great news. But it isn’t. Dan Bernstein has been ignored since 1999 when he said something should be done. I’ve been ignored since 2006. The IETF standardisation languished for two years.
This is not a success story. It has in fact been a remarkable failure.
To end on a positive note - I am very glad Dan Kaminsky’s work caused some collective eye opening, and I hope good things come from this. DNS has long lacked critical attention, and in the end this might bring about sorely needed improvements.
DNS very recently celebrated its 25th birthday - I look forward to seeing the venerable Domain Name System succeed in the coming 25 years!
I have a theory on what it is that Dan Kaminsky may have discovered that is broken with DNS (it was already _so_ broken, what else could be wrong?!) Basically it has to do with ICMP packets (spoofed ICMP unreachables sent in response to DNS packets the attacker can't see, but can guess - thanks to non-random port selection). The biggest problem with spoofing DNS at the moment is that you need to silence the real nameservers in order to get your fake replies in. For an ICMP response to be valid, it must contain the IP header of the packet it is a reponse too, but it also must contain 64bits of the data payload. The reason for requiring 64bits of the payload is to prevent people from spoofing ICMP replies to packets they have not received. In the case of a DNS packet, that payload is the first 64 bits of the UDP header. What is in the first 64bits of the UDP header? The source and destination ports of the DNS servers. If these are easily predictable then you can spoof an ICMP unreachable response to a dns query or reply without actually receiving it. If you can spoof ICMP; You can prevent the recursor from communicating with the real nameserver. This will make it very very easy to spoof DNS as it removes the biggest hurdle; that of silencing the real nameservers. It only takes about 2min on a 10mbit/s connection to run through all 65536 possible sequence numbers so if you can prevent the recursor from talking to the real nameservers it really is easy as pie.
Well perhaps this is a sign that the IETF standards process is broken, do you perhaps have any suggestions on how this can be improved.
If Dan Bernstein was not listened at _on this specific point_ (he made a lot of other claims on many subjects and a good part of them are wrong), it is not only because people were deaf or stupid but also because Dan Bernstein has... how to say? A big social interface problem.
What I resent in this blog/rant is the passive aggressiveness. "funny way of presenting things" "secret industry cabal". "the parties involved aren't to be lauded for their current fix. Far from it".
The current fix is the absolute best these parties could do at the moment. They have been told to fix it, and they fixed it.
"it has been known since 1999 that all nameservers were vulnerable for issues like the one we are facing now".
Just because Dan Bernstein implemented it, doesn't mean Dan Bernstein knew about this specific flaw.
"Let me repeat this. Wise people already saw this one coming 9 years ago, and had a fix in place"
Let me just say that this fix doesn't really help in the long run. Wise people would have implemented DNSSEC, or some other applied crypto to the DNS years ago. Most parties involved have done that, except for you and Dan Bernstein. So this is completely off the wall.
"but some months ago I noticed particularly strenuous resistance in the standardization of the so called forgery resilience draft, and after some prodding it became clear it was felt my draft was in danger..."
Paranoid rambling in need of several layers of tin foil. The draft was in need of some serious terminology fixes. Some folks helped out trying to get the text straightened out, especially since they knew what was about to be announced. They helped get the text standardized, and certainly did not try to stall things. IIRC, this draft was actually RUSHED and PUSHED to get a WGLC out sooner, rather than later, because of this issue.
"Dan Bernstein has been ignored since 1999 when he said something should be done. I've been ignored since 2006. The IETF standardisation languished for two years."
Both have ignored applied crypto in DNS (not just DNSSEC, basically any solution that _really_ fixes this issue). Since you know about this specific flaw, you know that the additional bits of randomness doesn't fix the problem in the long run. Moore's law. Bandwidth gets wider and cheaper, processing packets get faster and faster. The randomness in DNS messages including port randomization is fixed. What is your long term solution? Have you implemented one? Have you even thought of one? Have you helped developed one?
I think this post has it all just about wrong.
Hey Roy, in case you missed it, Paul Vixie said on the NANOG mailing list that he has known about this attack since 1995.
Also, DNSSEC has been six months away from completion for over a decade by now, hasn't it? If I had to choose a word to describe Bert Hubert's choice regarding PowerDNS and DNSSEC, it'd be "prudent" (rather than your "negligent").
The "serious terminology fixes" that were necessary to change in the I-D are all fine and dandy but you have to look at the slightly bigger picture. This standards track started out with alumni of the DNS world claiming that the I-D was unnecessary. The explicit reference in CERT's advisory conclusively proved the opposite.
Roy - many of the points you raise are valid. But if people would have implemented this years ago, we would be having a totally different discussion right now. And I sincerely hope that this vulnerability opens people's eyes and that we can fix DNS to be secure enough.
But it should be noted that djb is a real PITA, so if there's something he try to push it's very probable that people try to avoid it. And him. Don't get me wrong: this is all about behaviour and not about his programming abilities at all.
About DNSSEC, oh well, would be nice to have seen it finalised and implemented.
About DNSSEC, oh well, this is another "good solution to the wrong problem". (DNSSEC uses DNS protocol to propagate keys through DNS caches && DNS caches are vulnerables to cache poisoning = DNS keys may be forged ...) and If DJB was not listened at _on this specific point_ it is not only because he has a big social interface problem but also because IETF DNS-EXT WG people were... how to say? deaf or stupid.