By now, you probably know that details of the DNS vulnerability have leaked. Halvar Flake speculated on DailyDave and the momentum built from there, despite the fact that his guess was short on a few key details. I don't need to rehash the full technical details here; by now, they are easy enough to find with a couple Google searches. When Slashdot picks up the story, it's hardly a secret any more.

What's more interesting to me, now that I've digested the big secret, is how this whole situation has played out in the security community.

The security community has been polarized for the past two weeks, not so much over the technical details being withheld, but about Dan's plea that people not speculate about the vulnerability. As many pointed out, the "bad guys" won't stop trying to figure it out just because the "good guys" keep quiet. To be honest, my own lack of public speculation wasn't because I agreed with the philosophy; I just wasn't smart enough to figure out the vulnerability myself.

People implied -- or stated outright -- that Dan just didn't want anyone stealing his thunder. Considering the timing of the release and the subsequent BlackHat talk, it's obvious why such accusations were made. Personally, I think it's a little of each. I believe the coordinated patch effort was undertaken with the best of intentions, but I also think Dan relished some of the glory and media attention as well. It's hard to blame him for that; if you were in his shoes, wouldn't you want some recognition too?

By many accounts, dealing with the DNS vulnerability from the operational side has been an exercise in frustration. Plenty of IT people wanted to patch but couldn't get approval without being able to justify the operational risk. "Because Dan said so" is apparently not a convincing enough argument. Some wondered why the people who were responsible for creating the problem should be blindly trusted to implement an appropriate fix?

Ultimately, vulnerability disclosure is a minefield. No matter how you choose to disclose, somebody will always disagree.

P.S. If you didn't figure out the title of the post by now, Nate was one of the unlucky few to draw the same timeslot at BlackHat as Dan Kaminsky.

FREE Security Tutorials from Veracode

Cyber Security Risks
Mobile Security
CRLF Injection
Flash Security
SQL Injection Hack

Veracode Security Solutions

Software Security Testing
Binary Analysis
Application Analysis

Veracode Data Security Resources

Data Security Issues
Data Breaches
Data Loss Protection

About Chris Eng

Chris Eng, vice president of research, is responsible for integrating security expertise into Veracode’s technology. In addition to helping define and prioritize the security feature set of the Veracode service, he consults frequently with customers to discuss and advance their application security initiatives. With over 15 years of experience in application security, Chris brings a wealth of practical expertise to Veracode.

Comments (1)

BCreighton | July 22, 2008 10:54 am

The leaked attack is the kind of thing that anomaly-detection-engine device vendors have been salivating for since 2005. This is especially true for the attack variant that involves the attacker sending the RR questions himself, as well as the spoofed answers and the inevitable "probe questions" you'd have to send to find out when you finally guessed the ID correctly. (There are plenty of other ways to cause the questions to happen, but that's generally the one that requires the least amount of packets.)

Who wants to bet that every entity on <a href="" rel="nofollow">the CERT vendor list</a> that is also an IDS vendor has pushed out rules looking for requests that fit one or more of these patterns?

One problem with the embargo is that it's preventing discussion of attack detection and mitigation outside those put forward in the various announcements (ingress filtering, restricting recursion). Even those kind of got pushed to the background; the main message that got through to everyone was, "You need to patch."

Why are detection and mitigation important? Because you can still perform this attack even against a server serving queries from random source ports. It takes longer, but if there's nobody watching, that doesn't matter.

Please Post Your Comments & Reviews

Your email address will not be published. Required fields are marked *

Love to learn about Application Security?

Get all the latest news, tips and articles delivered right to your inbox.