Security [LWN.net]

Secrecy and the DNS flaw

By Jake Edge
July 9, 2008

By now, most folks will have seen reports of the design flaw discovered in DNS as it has seen fairly widespread coverage, even in the non-technical press. It is rare to see such a coordinated disclosure and security update amongst that many of the big players in the computer industry. While fixes abound, the actual problem has yet to be disclosed, which has both positives and negatives.

Responsible disclosure policies dictate that vulnerabilities be kept secret until all affected vendors can create an update. Because this flaw is in the design of DNS, most implementations were affected. This still doesn't quite explain the roughly six months between the discovery of the problem and the release of the fix. Evidently it took a meeting of the minds at the Microsoft campus in March to decide upon the right course of action. Once the fixes were done, presumably they were released on the next "patch Tuesday"—Microsoft's monthly security update day.

Normally, once fixes are available, information about the vulnerability is released. But, for a number of reasons, that has not happened in this case. One of the main reasons is that DNS is an essential internet service and it will take time for affected users to patch their systems. In addition, there have been no reports of this flaw being exploited "in the wild", reducing the pressure to divulge it.

Security researcher Dan Kaminsky discovered the flaw and he has yet another, "blatantly selfish" reason for keeping it quiet as he would like to be able to announce it at Black Hat in Las Vegas in early August:

While I'm out there, trying to get all these bugs scrubbed — old and new — please, keep the speculation off the @public forums and IRC channels. We're a curious lot, and we want to know how things break. But the public needs at least a chance to deploy this fix, and from a blatantly selfish perspective, I'd kind of like my thunder not to be completely stolen in Vegas.

None of these seem like horrible reasons to keep the vulnerability quiet for a time (roughly 30 days), but they do leave some DNS implementations and worried administrators without the information they need to evaluate the situation. Administrators do not know what traffic patterns or other symptoms to look for to determine if exploits are being attempted. Smaller, less prominent DNS implementations were not included in the collaboration, thus they don't have enough information to decide whether they are vulnerable or not.

A perfect example is Dnsmasq, a lightweight DNS server for smaller networks. Dnsmasq is often used in embedded Linux distributions targeted for home wireless routers. Simon Kelley, Dnsmasq developer, was asked about the vulnerability; his response speaks volumes:

I wasn't contacted in advance about this, and no patch for dnsmasq has been released. Since the exact nature of the new vulnerability has not (as far as I know) been announced, I don't know if dnsmasq is vulnerable.

Kelley has since released a patched version, but it is still unknown whether it is needed or, really, if it even fixes the problem. It is difficult to know for sure that a security hole has been closed if information about the hole is not available. This points to the problems that can come from withholding vulnerability information.

Based on the patches and some information from Kaminsky and others, it is clear that this is a cache poisoning vulnerability. Since source port randomization is the change that was applied to alleviate, but not eliminate, the flaw, we can surmise that Kaminsky found a way to reduce the number of spoofed replies that need to be sent to something tractable. According Internet Systems Consortium, developers of the BIND DNS server, the only true solution is DNSSEC, which implies that the current fixes only make cache poisoning less likely, not impossible.

Source port randomization is a technique that has been advocated by Daniel J. Bernstein (i.e. djb) for many years. He implemented it in his djbdns name server long ago. Essentially, it chooses a random source UDP port for each query that the name server makes, which has the effect of increasing the randomness that an attacker needs to be able to predict before being able to poison the cache.

While the market share of Dnsmasq may be miniscule, there are certainly other DNS implementations that are also concerned. In addition, we are relying on those who are "in the know" to be on the lookout for suspicious traffic that might indicate the vulnerability being exploited. Kaminsky is certainly under no obligation to reveal anything, but one wonders if the safest course would have been for him to provide details now, even at the expense of his "thunder".

Comments (15 posted)

Security news

Dan Kaminsky Discovers Fundamental Issue In DNS: Massive Multivendor Patch Released (Securosis.com)

Dan Kaminsky has found a flaw in the design of DNS that can allow cache poisoning as an article at Securosis.com details. This has lead to a CERT advisory as well as a coordinated release of patched DNS servers from all affected vendors. Evidently source port randomization is helpful in alleviating the problem. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not immediate reveal the vulnerability and reverse engineering isn't directly possible." That last claim seems rather strong, time will tell, but it makes sense to be prepared to upgrade affected servers as soon as distributions make them available.

Comments (28 posted)

Mozilla Foundation developing a model for a security metric (heise online)

An article at heise online describes Mozilla's new security metrics project, which is an attempt to measure the relative security of Firefox. "One of the main factors cited is how long Firefox users are exposed to a threat while a hole remains unpatched. The developers say they want to use the security metric derived from the results to identify any problematic stage in the development and patch process."