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
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
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
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
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
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
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".
to post comments)