In-Depth

DNS Flaw Ignites Controversy

A security researcher's speculation about a DNS flaw ignites another firestorm for full and responsible disclosure

• By Stephen Swoyer
• 07/29/2008

Earlier this month, researchers disclosed an ominous-sounding DNS vulnerability. It was said to affect products from about 80 different vendors -- in part because fixing it involves a fundamental redesign of existing DNS resolver implementations (see http://www.esj.com/security/article.aspx?EditorialsID=3235).

Last week, researcher Thomas Dullien -- CEO at security firm Zynamics -- outlined his own take on what the DNS issue entails. Dullien posted his thoughts on his blog, ADD/XOR/ROL, under the nom de plume "Halvar Flake" and once again stoked the still-simmering debate between advocates of "full" disclosure and those favoring "responsible" disclosure. Dullien, for his part, seems to champion the former position -- at least when it comes to speculation about the nature of a vulnerability.

"I know that Dan Kaminsky [the security researcher who first discovered the flaw] asked the public researchers to 'not speculate publicly' about the vulnerability in order to buy people time. This is a commendable goal. I respect Dan's viewpoint, but I disagree that this buys anyone time," he wrote, countering, however, that "if nobody speculates publicly, we are pulling wool over the eyes of the general public, and ourselves."

If disclosing a vulnerability can give a bright -- but not necessarily expert -- security researcher enough materiel to reverse-engineer a vulnerability, Dullien asks why the security community as a whole should foster a sense of "false security" by prohibiting speculation about what's at stake.

He went on to outline a scenario in which an "average" person with "some" security experience might take "N" days to figure out a problem, based largely on a description -- independent of specific details or corroborating facts -- of the problem. The purpose of a blackout like the one advocated by Kaminsky, Dullien continues, is to "buy people time" -- that is, to prevent an "evil" person from figuring out and exploiting a vulnerability before "N" time has elapsed.

An admirable goal, Dullien agrees, but it doesn't take into account the scheming of an extremely bright evil person with extensive security experience.

Nor, for that matter, does it take into account the experimentation of a curious white-hat security researcher. In both cases, the time to "N" -- to figuring out the problem -- is likely to be much shorter.

"This person is smart, and has a clear financial incentive to figure this out. I'd argue that it would take him N/4 [i.e., N-divided-by-4] days," Dullien argues. "By asking the community not to publicly speculate, we make sure that we have no idea what N actually is. We are not buying anybody time, we are buying people a warm and fuzzy feeling." For example, he suggests, "It is imaginable that N is something like 4 days. We don't know, because there's no public speculation."

Dullien buttressed his own thought experiment in effect by figuring out the nature (and many of the basics) of the flaw. Dullien downplayed his theory -- citing his own inexperience with DNS -- but researchers with knowledge of the flaw confirmed that he had many of the details correct.

"The last weeks I was in the middle of preparing for an exam, so I really didn't have time to spend on the DNS flaw. I couldn't help myself … and spent a few minutes every other evening or so reading a DNS-for-dummies text. I have done pretty much no protocol work in my life, so I have little hope [of] having gotten close to the truth," Dullien conceded.

His speculation describes a DNS spoofing attack in which an attacker wants to "poison" DNS server lookups on a specific name server (NS) for a fully qualified domain name (FQDN) address. The exploit involves an attacker hammering a target NS with fake requests for a domain that the NS itself doesn't have cached; a root name server then refers the target NS to a .com name server; from there, the attacker spoofs referrals -- which purport to originate from the .com NS, but which, in fact, point to a bogus address (e.g., his or her own IP address) -- and sends them to the target NS. The point, Dullien says, is that -- at some point -- the attacker will correctly spoof one of these referrals, with the result that the target NS will cache a bogus URL (typically that of the attacker) for the FQDN.

Dullien's work might have gone unnoticed if it hadn't been picked up by a security firm that was privy to the details of the vulnerability.

In a post that was later retracted, security researcher Matasano confirmed Dullien's basic account. By the time Matasano deleted the post and apologized for the disclosure, other sites had already picked up and mirrored its original explanation (see http://beezari.livejournal.com/141796.html).

"Earlier today, a security researcher posted their hypothesis regarding Dan Kaminsky's DNS finding," wrote Matasano principal Thomas Ptacek. "Shortly afterwards, when the story began getting traction, a post appeared on our blog about that hypothesis. It was posted in error. We regret that it ran."