Slashdot Mirror
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.'"
I just remember the IP addresses and type them in myself. How hard is that?
ccalam - acoustic versions of new songs.
ive never had to change tinydns installs for security reasons
Why UNIX?
this article at information week said it best the day after the announcement.
Geez, if you want responsible disclosure, you have to trust the experts when they say "it's new and it's bad"
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.
Security expert discovers flaw
Tries to do the right thing and report it responsibly to vendors. Coordinates patch day responsibly.
People ignore it/blow it off/procrastinate and then proceed to throw blame and lawsuits against those who tried to help them in the first place.
They require a license to drive a car on a highway. Sure as hell would thin out the herd to require a license to drive a server on the information superhighway.
What is Secure DNS and where is the wikipedia article? Anybody?
From Paul Vixie's response: "Tom Cross of ISS-XForce correctly pointed out that if your recursive nameserver is behind most forms of NAT/PAT device, the patch won't do you any good since your port numbers will be rewritten on the way out, often using some pretty nonrandom looking substitute port numbers."
Does this mean that a typical small-business setup isn't protected by the patch?
For example, a server which provides recursive DNS and which connects to the Internet by a "cable" modem.
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.
I scream. You scream. I assume that means we're both acquainted with the problem. We proceed.
Oops! I meant cable router, not cable modem
It depends on how the NAT device assigns port numbers to outgoing queries. Apparently the fix for this flaw is to ensure the source port for lookups is truly random; some devices may use very predictable sequences (such as our Cisco ASA at work, mutter mutter).
If you visit Dan Kaminsky's blog, there's a DNS checker in the right hand panel which allegedly tells you if you need to worry or not. It just looks to see if all your queries for their test domain name came from the same port number.
Just another reason to make your local DNS forwarder use OpenDNS, or if you don't have one on your LAN, direct your router/workstations to OpenDNS. If your small-business LAN is relying on your provider's DNS, hopefully they patched it. Most worth their salt have, but OpenDNS also provides many features that are useful to small-business (in addition to not having been vulnerable to the flaw).
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?
Only if you have a method for authenticating the other side of the phone conversation.
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's a specific phrase to describe it, but it escapes me at the moment.
Bascially, when you have a crowd of people standing around watching someone get beat up, nobody steps in to help, because everyone assumes someone else will help.
Verifying source code is somewhat like that: someone else will do it. The great thing about the internet is the crowd is so large that the few people, who would jump in no matter what, are always present.
[Fuck Beta]
o0t!
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.
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
Uh oh, somebody call the whaaaaambulance, we're going to need to perform a humor transplant here!
- None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
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.
User ID 1352 trollin' it old skool!
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!"
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.
The patch is now in my crontab and set to run on the 6th.
#DeleteChrome
Of course they are. They stopped ignoring their mom shouting down into the basement that it was dinner time a LONG time ago. ;)
Wouldn't that make it easier for an attacker to exploit your local DNS?
You just told him, that his fake DNS-responses should appear to come from either 208.67.222.222 or 208.67.220.220.
alias sudo="echo make it yourself #" ; # https://pipedot.org/~stderr & http://soylentnews.org/~stderr
Do you write plot themes for Hollywood?
The problem with conspiracy theories is that everyone involved in the conspiracy must keep silent, or else the conspiracy will be outed. Most people have a lot of trouble doing that because let's face it -- our egos are just too big. Unfortunately (or fortunately, depending upon whether or not you're in on the secret), once anyone else knows, everyone else knows.
So yeah, that sounds like it would be a great exploit, but do you really think it is likely that anyone could convince everyone involved to be a part of such a conspiracy? Surely *someone* would have refused, and to date, the only person I know of who is even loosely connected with FOSS that has...ummm...disappeared...lately is the late Mrs. Reiser.
But okay, let's assume you're right. So, Dan Kaminsky and Paul Vixie and everyone else involved manage to do what you described despite the problems I mentioned. Has everybody patched? Yeah, they created quite a scare, but sys admins are a skeptical, paranoid bunch. Surely someone left an unpatched system or kept the source code for the unpatched versions of the major DNS servers hidden away somewhere -- even if only the FOSS versions. So if on August 7th, everything goes to ****, a bunch of people roll back to the old version. Yeah, the world's largest beowulf cluster of bots is still running, but the really paranoid guys are busy rolling back to unpatched DNS servers, and are working on patches for all the compromised systems. Assuming that Kaminsky, Vixie and co. aren't bludgeoned to death by a mob of angry sys admins, how long do you think it will be until it's business as usual again?
MCSE? No, sir...I don't do Windows. Yes, I am an idealist. What's your point?
I did the "dig" test on my patched DNS servers, and one of them failed.
Reason: It was connected to an ADSL router by a 192.168.1.0/24 subnet which was translated by port S-NAT to a narrow range of source UDP ports.
As a result, all of the fixing of the DNS servers was made useless.
It was only the "dig porttest.dns-oarc.net in txt" test which exposed this.
Not that you should really do:
dig @your.dns.server porttest.dns-oarc.net in txt
where your.dns.server is the local DNS server behind your ADSL router or firewall which you want to test. Otherwise you don't really know _which_ server you are testing.
So I reconfigured my ADSL modem and that is okay now.
However...
On another site, the above "dig" test shows that everything is GOOD. But that is an illusion. What happened is that when the "dig" command is pointed with "@" at the local port of the ADSL router, the ADSL router's built-in DNS server uses the ISP's two DNS resolvers, and the _ISP's_ servers are patched. But the ADSL modem DNS requester is using fixed UDP source ports.
I can't find any definite confirmation of this. But I think this scenario is just as vulnerable as the worst case, even though the "dig" test says GOOD.
Cheers,
Alan.
Chuck Norris doesn't type in IP addresses by hand. He just whistles the modem tones.
But doesn't he use broadband instead of dialup? When Chuck Norris whistles for a modem, it does what he wants real fast.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Unfortunately, as Vixie admits, DNSSEC has intractable problems [...]
So... why is Vixie recommending it? It's about as secure as using PGP without the web of trust, or using HTTPS without the PKI.
It would make sense if he didn't admit that there were intractable problems, and then told people to use it. Or if he said that there's really nothing you can do, and that the DNS vendors dropped the ball somethin' fierce by failing to secure the system in the decade since the problem was described.
But what is he even thinking?
Bah; enough dithering. It's time to cue the folks who're going to point out that djb is a big meanie, therefore nobody should rag on Vixie. Flying monkeys, away!
Laws do not persuade just because they threaten. --Seneca
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?
No, but given the "number of eyes", it's usually not necessary that every person has read every line of code. If a set of N people have read the relevant code and understand it, that's often sufficient to solve a problem.
I ran across an example just a few days ago. The details aren't too important here; the critical point is that I and others were getting an error message didn't agree with what we could see clearly. A bit of detail: CUPS sometimes reports that a printer is permanently "busy", when you can tell by just looking at the printer that it's idle. I googled the message, several of the first hits were pointers to the source code, and the message was in a block that started:
if (error == ECONNREFUSED || error == EHOSTDOWN || error == EHOSTUNREACH) { ...}
The definitions of those error codes are easy to find, and none of them includes the concept of "busy". So the error message is bogus and misleading; the actual error was some sort of failure to connect to the IP address used. At this point, the search becomes tricky, because the error message doesn't report the actual error code. Someone needs to hunt down and understand all the places in the code where any three of those error codes is generated.
But note that an important part of the answer has been determined from just this code fragment: The error message is wrong. The printer isn't known by the software to be "busy". The actual problem is failure to get a TCP connection. And it's highly likely that various people in the collection of hackers will know what to do to diagnose all of the three possibilities. Without access to the source code, we would know none of this. We'd be blocked at the error message claiming that the printer is busy, and we'd have no further clues.
Also, since the code is "free" (as in freedom), there's a good chance that down the road we can replace the current bogus error message with something that does a better job of informing the user about the actual problem. Without the freedom to modify the source code, we'd be dependent on a vendor's good will. And, since this problem arises in trying to deal with equipment from a different vendor, chances are that the vendor would give it very low priority.
And look up RMS's story of how he started on the road to the "software freedom" concept. It was dealing with problems he was having with a printer that didn't play nice with his computer. This problem is still with us. All too often, such problems can't be solved without access to the source code. It's quite common to see error messages that don't include significant information. In this case, the actual error code wasn't reported, making diagnosis very difficult for novice and expert alike. With proprietary code, there's little that a user can do. With FOSS, we stand a chance of improving the error messages regardless of the level of interest of the vendor.
(But this was only a few days ago. That printer still isn't working with that one computer, but does work with a different computer in the same room. ;-)
Those who do study history are doomed to stand helplessly by while everyone else repeats it.