Slashdot Log In
Paul Vixie Responds To DNS Hole Skeptics
Posted by
kdawson
on Tue Jul 15, 2008 07:07 AM
from the be-afraid-be-very-afraid-then-get-patching dept.
from the be-afraid-be-very-afraid-then-get-patching dept.
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.'"
Related Stories
[+]
IT: Massive, Coordinated Patch To the DNS Released 315 comments
tkrabec alerts us to a CERT advisory announcing a massive, multi-vendor DNS patch released today. Early this year, researcher Dan Kaminsky discovered a basic flaw in the DNS that could allow attackers easily to compromise any name server; it also affects clients. Kaminsky has been working in secret with a large group of vendors on a coordinated patch. Eighty-one vendors are listed in the CERT advisory (DOC). Here is the executive overview (PDF) to the CERT advisory — text reproduced at the link above. There's a podcast interview with Dan Kaminsky too. His site has a DNS checker tool on the top page. "The issue is extremely serious, and all name servers should be patched as soon as possible. Updates are also being released for a variety of other platforms since this is a problem with the DNS protocol itself, not a specific implementation. The good news is this is a really strange situation where the fix does not [immediately] reveal the vulnerability and reverse engineering isn't directly possible."
[+]
IT: RHN Bind Update Brings Down RHEL Named 312 comments
alexs writes "Red Hat's response to update bind through RHN, patching the DNS hole, made a fatal error which will revert all name servers to caching only servers. This meant that anyone running their own DNS service promptly lost all of their DNS records for which they were acting as primary or secondary name servers. Expect quite a few services provided by servers running RHEL to, errr, die until their system administrators can restore their named.conf. Instead of installing etc/named.conf to etc/named.rpmnew, Red Hat moved the current etc/named.conf to etc/named.conf.rpmsave and replaced etc/named.conf with the default caching only configuration. The fix is easy enough, but this is a schoolboy error which I am surprised Red Hat made. Unfortunately we were hit and our servers went down overnight while RHN dropped its bomb and I am frankly surprised there has not been more of an uproar about this."
[+]
IT: The Backstory of the Kaminsky Bug 53 comments
Ant recommends a Wired piece on the background story of the Kaminsky DNS bug and its (temporary) resolution, decreasing the odds of a successful breach from 1 in 2^16 to 1 in 2^32. We've discussed this uber-hole a number of times. Wired follows the story arc from before Kaminsky's discovery of the bug to his public presentation of it in Las Vegas.
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
I'm not worried (Score:5, Funny)
Re:I'm not worried (Score:5, Interesting)
Parent
Re:I'm not worried (Score:5, Funny)
Why is that hard? Still works with IP-addresses. The only thing you need to do is to supply the Host-field as per HTTP/1.1.
Parent
Re:I'm not worried (Score:5, Funny)
That's why 'smart' people use /etc/hosts. That solves the problem of remembering and of the HTTP-host-header.
Parent
Re:I'm not worried (Score:5, Funny)
I just remember the IP addresses and type them in myself. How hard is that?
That's all well and dandy until banner ads start flashing subliminal messages of unauthorized zone updates to you.
Parent
Re:I'm not worried (Score:4, Funny)
Parent
Re:I'm not worried (Score:4, Insightful)
Parent
Re:I'm not worried (Score:5, Funny)
Hey!
I am an unpatched DNS server, you insensitive clod!
Parent
The back-biting is shameful (Score:5, Insightful)
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
Re:The back-biting is shameful (Score:5, Insightful)
So, you figure eighty vendors coordinated a simultaneous patch for some issue that is not really a big deal, probably just some guys vying for attention?
Parent
It's all a liberal plot (Score:5, Funny)
DNS cache poisoning is a myth cooked up by the liberal media and DNS scientists to implement their anti capitalist agenda.
And if it isn't a myth, then it certainly isn't man made, it's a natural phenomenon and there's nothing we can do about it.
Parent
Re:The back-biting is shameful (Score:5, Funny)
If there's one thing that everyone should have learned by now, if someone says "trust me", you should be skeptical.
No, you're off message. They need to click continue, because the screen has gone all dark and they can't get back to their web browser.
Parent
Re:The back-biting is shameful (Score:5, Interesting)
That same information that allows you to make an "informed decision", as you so blithely put it, puts the integrity of the entire infrastructure and, more to the point, the information security of a whole lof of people at tremendous risk. Dammit, that's the whole point of the OP's observation and why people argue about disclosure in the first place.
Parent
Re:The back-biting is shameful (Score:4, Interesting)
Vixie claims that "Everything we thought we knew was wrong", but at the same time, we know that there are DNS systems and services that did not have this vulnerability, so obviously some people had already given this type of issue some thought.
No. Not all dns systems/services may be vulnerable, but this might not be because of forethought but rather a different design paradigm (buzzword alert, I know). They might just have been designed differently for other reasons, and non-vulnerability to this exact flaw may be a side-effect.
Parent
Re:The back-biting is shameful (Score:5, Insightful)
Sure you would; and the blame for any damage would be blamed on who made the disclosure.
There is nothing wrong with how this was/is being handled. Limited disclosure with a solid and "reasonable" deadline is a perfectly fine way to balance the myriad issues with security threats.
Parent
Doctors make the worst patients (Score:5, Insightful)
Knowing how to run a system is not purely technical knowledge, it's also a measure of professional ability. That means knowing when to take advice, and knowing who to take it from.
So, are we all compiling from source all the time? (Score:4, Insightful)
All paranoid theories about this issue sort of ignore the fact that unless you plan to install hundreds (or even thousands) of systems from your own compiled source for years and years to come, all of this discussion is at best academic.
The new distros are going to have the patch.
And really, considering the number of prehistoric vulnerabilities that should have been patched, that this one is finally getting patched is fine.
Yeah, there's a bit of "trust me" factor here with this patch, but a lot of good people are putting their credibility on the line for this patch.
All of this whole FOSS thing entails a lot of trust. I mean, you're really telling me that everyone on here whining about the need to see the source code has read every line of code in every OS they're using? There is a level at which we're all sort of hoping that the guys interested in each of the particular parts of the OS have done a thorough job in their separate efforts.
So its not the same flaw? (Score:4, Informative)
Q: "This is the same attack as described way back in
A: No, it's not.
When Dan Kaminsky states in his blog. [doxpara.com]
"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? (Score:5, Informative)
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.
Parent
Re:So its not the same flaw? (Score:4, Informative)
Parent
A simple test to run (Score:5, Informative)
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:
FAIR or GOOD means you're ok, but POOR (which is the result I got) means you should be worried.
Re:What is Secure DNS (Score:5, Informative)
"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
Parent
Re:Unfortunately, what else is new? (Score:5, Funny)
Your mad ad hominem attack skills have convinced everyone that Paul Vixie is the know nothing douchebag in this conversation. Kudos!
Parent
Re:Unfortunately, what else is new? (Score:4, Funny)
Parent
Re:Unfortunately, what else is new? (Score:4, Informative)
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.
Parent