There has been a lot of speculation devoted to the impending release of information about a DNS vulnerability discovered and initially announced by Dan Kaminsky almost two weeks ago. A lot of the coverage has been back and forth arguing about whether what has been discovered is relevant or not but the best thing to have done in the intervening period is to have sat on your hands and waited.

As far as the facts stand what is being claimed is that there is a design flaw in all DNS servers that can be exploited to lead to spoofing of results. As US-CERT state, "Recent additional research into these issues and methods of combining them to conduct improved cache poisoning attacks have yielded extremely effective exploitation techniques".

Dan Kaminsky is a well respected name in Information Security research and so, despite the initial rush to dismiss this seemingly outlandish claim, chances are that something significant has been uncovered. These chances are enhanced by the number of DNS server vendors who have gotten on board with updates to their products. Surely there wouldn't be so many to have contributed updates if there was nothing in the claims.

It shows how bodies such as the various CERTs have significant value, being able to act as a central distribution point of information and having the ability and weight of presence (even if they don't always have the legislated authority) required to get vendors to commit to addressing issues raised.

When respected names such as Thomas Ptacek came out swinging against the flaw being anything new it set the scene for an ongoing argument that is not likely to be settled until at least the full release at Black Hat, and even that is no guarantee that the argument will be fully settled. Ptacek has reversed his initial position after being able to talk to Kaminsky directly, but how many of those who are supporting or critical of the finding will be able to do the same?

Kaminsky acknowledges that even if the majority of systems don't get up to the required standard to protect against his discovery, it will still be a huge win if they get up to the standard required to neutralise some of the other critical DNS related vulnerabilities that have surfaced in the last couple of years.

Kaminsky also acknowledges that a lot of the skepticism has been deserved but with groups such as the ISC claiming that the discovered vulnerability has previously been known about the wider industry should not expect to resolve it in a hurry. Reverse engineers who quickly jumped on Microsoft's MS08-037 when it was released last week have identified that it has something to do with poor entropy with source ports and transaction IDs, but that led to a bit of an odd observation, recorded by IBM's Tom Cross.

Cross picked up on a Full Disclosure posting by 'imipack' that pointed out that DNS responses from a nominally patched server would still provide sequential UDP source ports when the recipient system was behind a NAT firewall/networking device. Cross believes that this behaviour is consistent across all NAT devices and not just the one tested by imipack (other mailing list contributors confirmed the behaviour on some big name equipment).

The outcome from this is that successful source port randomisation by the DNS server breaks down when it encounters a NAT device enroute to the client system. While using a NAT device in a network is normally a great idea, in this case it actually decreases the available security for the end user. Cross recommends that administrators who are running a caching DNS server behind a NAT device should move them into a DMZ where they can obtain their own IP address. With this information in the open, even if the majority of the web's DNS Servers are successfully patched, the risk to end users remains significant. Fortunately solutions have already been found, mainly to use ipchains in MASQUERADE mode for the NAT, which allows preservation of the randomised source ports, and pf which also randomises the source port for NATed connections.

With the currently increased levels of DNS traffic (purported to be updated servers re-establishing their caches), and the above discovery about NAT device behaviour, some have laid out a reasonable expectation that corporate systems could be turned inside out with ease using blended attacks that make use of DNS spoofing, the NAT device behaviour, and other readily available exploit techniques.

One of the bigger questions that will hopefully be answered with Kaminsky's presentation is why the known method of source port randomisation is an effective defence against this new vulnerability. Is it a lucky side effect of the pre-existing implementation efforts (it is surprising how often that turns out to be the case), or is it a direct means to address the design flaw? Kaminsky acknowledges that the protection that DJBDNS has had for many years through source port randomisation is down to the excellent design of the product. Excellent design and implementation is your best preventative measure to protect against vulnerabilities that you haven't yet heard about.

While we know that the vulnerability is a design flaw, whatever the final answer everyone will be keenly watching in early August to find out. Kaminsky has even asked the security community to turn their eyes onto DNS and help make sure that he hasn't missed anything and to do everything they can to ensure that what is left is secure. Those who have peer reviewed his findings have already begun on this process but the rest will have to wait until August.