Rich Mogull's executive overview of Dan Kaminsky's latest DNS vulnerability fluffed a few feathers yesterday:

The good news is that due to the nature of this problem, it is extremely difficult to determine the vulnerability merely by analyzing the patches; a common technique malicious individuals use to figure out security weaknesses.

The typical response I heard was "what do you mean, it can't be reverse engineered? I'll just look at the diffs!"

In hindsight, after examining the BIND diffs (yes, I did it too) and discussing with colleagues, all most people saw was UDP source port randomization and a better PRNG for generating the transaction ID, the latter of which would appear to be related to Amit Klein's cache poisoning attack from about a year ago.

What Rich was really saying is that you can reverse engineer the patch until you're blue in the face, but that won't reveal the specifics of the vulnerability.

Dan's blog post this morning appeared to confirm that interpretation:

DJB was right. All those years ago, Dan J. Bernstein was right: Source Port Randomization should be standard on every name server in production use.

There is a fantastic quote that guides a lot of the work I do: Luck is the residue of design. Dan Bernstein is a notably lucky programmer, and that’s no accident. The professor lives and breathes systems engineering in a way that my hackish code aspires to one day experience. DJB got “lucky” here — he ended up defending himself against an attack he almost certainly never encountered.

Such is the mark of excellent design. Excellent design protects you against things you don’t have any information about. And so we are deploying this excellent design to provide no information.

To translate the fix strategy into a more familiar domain, imagine large chunks of Windows RPC went from Anonymous to Authenticated User only, or even all the way to Admin Only. Or wait, just remember Windows XPSP2 :) This is a sledgehammer, by design. It cuts off attack surface, without necessarily saying why. Astonishingly subtle bugs can be easily hidden, or even rendered irrelevant, by a suitably blunt fix.

Nate McFeters appears to think that Tom Ptacek has figured it out. I'm going to go out on a limb and say that Tom didn't figure anything out yet but still wanted to write a pithy blog post. I think that if Tom had figured it out, he would have written it down privately and posted the SHA-1 hash, as is the trendy thing to do these days.

Speculation aside, the title of Tom's blog entry, Dan Kaminsky could have made hundreds of thousands of dollars with this DNS flaw!, does make an important point -- Dan didn't sell the details to ZDI, he used his influence and reputation to coordinate a massive vendor patch effort. That's an admirable move.

Veracode Security Solutions
Veracode Security Threat Guides

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 (5)

Thomas H. Ptacek | July 9, 2008 12:50 pm


I'll publish the nonce later.

CEng | July 9, 2008 12:52 pm

The plot thickens!

TK | July 9, 2008 12:56 pm

I have worked with Tom before, and if anyone figured it out, my money would be on him...

CEng | July 9, 2008 1:07 pm


I agree, he would be on my short list of "people who might figure it out." I wouldn't have egged him on otherwise. :)

Thomas Ptacek | July 9, 2008 7:33 pm

All I'll say now is this: I'm unlikely to ever tell you what the nonce was for that hash.

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.