Paul Vixie Responds To DNS Hole Skeptics

syncro writes "The recent massive, multi-vendor DNS patch advisory related to DNS cache poisoning vulnerability, discovered by Dan Kaminsky, has made headline news. However, the secretive preparation prior to the July 8th announcement and hype around a promised full disclosure of the flaw by Dan on August 7 at the Black Hat conference has generated a fair amount of backlash and skepticism among hackers and the security research community. In a post on CircleID, Paul Vixie offers his usual straightforward response to these allegations. The conclusion: 'Please do the following. First, take the advisory seriously — we're not just a bunch of n00b alarmists, if we tell you your DNS house is on fire, and we hand you a fire hose, take it. Second, take Secure DNS seriously, even though there are intractable problems in its business and governance model — deploy it locally and push on your vendors for the tools and services you need. Third, stop complaining, we've all got a lot of work to do by August 7 and it's a little silly to spend any time arguing when we need to be patching.'"

Comments

Re:What is Secure DNS

[Anonymous Coward]

"The Domain Name System Security Extensions (DNSSEC) are a suite of IETF specifications for securing certain kinds of information provided by the Domain Name System (DNS) as used on Internet Protocol (IP) networks. It is a set of extensions to DNS which provide to DNS clients (resolvers):

        * Origin authentication of DNS data.
        * Data integrity.
        * Authenticated denial of existence."

http://en.wikipedia.org/wiki/DNSSEC

Re:Unfortunately, what else is new?

[gregmark]

Randomizing UDP source ports does not solve the problem, it only makes it more difficult to impersonate the responding DNS server. Secure DNS makes this kind of impersonation impossible, or at least allows us to bask in the warm glow of impossible.

The DJB vs BIND thing is an illusion. Whatever everyone agrees is the best implementation should win and I doubt that Paul Vixie or anyone else at ISC thinks differently.

But it has become abundantly clear to me that DJB and his minions (of which I assume you are one) have failed to matter in most ways, not because of your ideas, but because of the brusque, immature manner in which those ideas are submitted for consideration, outside the standards committees which have served the Internet well for 30 years.

So its not the same flaw?

[BOFslime]

I'm having trouble with Paul Vixies' line:

Q: "This is the same attack as described way back in ."
A: No, it's not.

When Dan Kaminsky states in his blog.

"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."
and
" 1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?

Re:So its not the same flaw?

[hal9000(jr)]

1) It's a bug in many platforms 2) It's the exact same bug in many platforms (design bugs, they are a pain) " How is this not the same flaw DJB described?

You are looking at two separate issues. The flaw Kaminsky found is apparently a newly discovered design flaw that makes DNS forging easy even with todays, unpatched DNS servers. In the advisory, they discussed previous problems with generating the transactionID to explain the problem and point out that what Dan found is not something already known (alot of people missed that very obvious point).

The second seperate, issue is UDP source port randomization. That is what Kaminsky was referring to DJB's solution. Kaminsky's assertion is that UDP source port is a good development practice which DJB incorporated into his DNS server.

Bear in mind that UDP source port generation doesn't solve the underlying problem, it simply makes blind DNS forging more difficult because now an attacker has to guess both a pseudo random transaction ID and a pseudo random UDP source port number. Alot of DNS servers and OS, simply picked source port numbers incrementally or in the case of a DNS server, re-used the some one over and over.

I don't know hom much more difficult DNS forging will be by randomizing the UDP source port numbers. The additional keyspace is (2^16-1023) and you can probably divide that in half again. But it's better then nothing and probably provides enough time (the time it would take an attacker to blindly guess the transactionID and UDP source port number) for the actual response to hit the DNS server. In DNS, the first response wins.

Re:So its not the same flaw?

[xrayspx]

DJB's source port randomization makes it much much harder to exploit the main bug, which is apparently a fundamental flaw in the DNS. We'll know on the 7th what that flaw is, but until DNSSEC or something similar is implemented, source port randomization will mitigate the risk until such time that the root cause is fixed.

Re:The back-biting is shameful

[Lennie]

It was because of forethought of one man, DJB (Bernstein).

A simple test to run

[GeorgeK]

In a comment to a question I posted for the CircleID article, Paul Vixie posted a nice and simple test that people can run to see how vulnerable they are:

dig porttest.dns-oarc.net in txt

FAIR or GOOD means you're ok, but POOR (which is the result I got) means you should be worried.

Re:A simple test to run

[jroysdon]

Many older named.conf configs have "query-source port 53;". While this is nice for firewalls to open up DNS traffic (assuming replies from source udp/53 to destination udp/53 (your query port) are always safe), it makes it easy to exploit.

This must be removed and those nameserver restarted. I had to do this with all of my servers, otherwise all queries come from the same port (53). Complain to your ISP if you find this to be the case with their DNS servers and in the meantime use some other DNS servers.

My two local Comcast resolves show "Poor" as the ports they use only have a standard deviation of 130-150, which I guess is assumed to be far too obvious and easy to keep bombarding.

Second, your NAT router may be de-randomizing your DNS queries if you run a resolver at home, and taking your random ports and putting them in order starting at 1024 (or something similar).

My own local/internal DNS servers shows as a std dev of 9 since my PAT router is de-randomizing the external ports. I'll be replacing my PAT router.

Third, your NAT router may be your DNS resolver and may not be using random source ports.

Diffusion of Responsibility

[CrankyFool]

You're looking for Diffusion of Responsibility, made famous by the incident in which Kitty Genovese was murdered within earshot of a whole bunch of people, all of whom thought "damnit, someone should do something about this!"