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"
If he posted that here, it would get modded Flamebait or Troll.
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.
You don't want to be lagging behind the competition. First on the unpatched box owns it.
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.
Today at Black Hat the DNS exploit was explained and demonstrated in full. After getting 98% of the systems running DNS to apply an urgent patch it was disclosed that the patch was the hack. All patched DNS servers were then compromised during the Black Hat demonstration. This shows how a process can be used to introduce code that allows an outside entity full control of all systems on the network. During the demonstration Dan repeated his statement, "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." Obviously he was refering to all the work he had to do to coordinate the largest take over of the Internet. A bot net of 100,000,000 systems was created in just a few minutes.
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?
I don't find the patches. Am I in a risk ?
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.
In other words, what he's saying is: "Take this new thing and deploy it, even though I admit it doesn't and can't work properly."
And this man doesn't see a problem with his logic? He must be certifiable.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Only if you have a method for authenticating the other side of the phone conversation.
I only take Bruce Schneier's word without peer review.
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!"
"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)." - by socsoc (1116769) on Tuesday July 15, @09:34AM (#24194965)
You may have to "watch it" though, with ActiveDirectory (AD) networks (or, possibly OTHER directory services too, that are heavily dependent on DNS services)... E.G.-> Using OpenDNS &/or ScrubIT DNS servers!
For example:
Using external DNS servers can "mess up" FULL Outlook's connections to Microsoft Exchange Servers on an internal ActiveDirectory network!
(I've seen it happen, & even listing another INTERNAL one as the "secondary DNS server" didn't seem to help on a job I was @ last year/earlier this year - @ least not w/ out using some "extra layered work-arounds" like VPN's & such)...
----
It makes sense they would make things on an AD LAN/WAN funny, for some things @ least, & email's pretty important as one that gets messed up:
I mean - How on earth could an external-to-your-LAN/WAN DNS Server know about your internal & probably NON-ROUTABLE IP Address servers (static types - 10.x.x.x/172.x.x.x) or even DCHP assigned addy ones (192.168.x.x etc.) & their IP assignments?
From what I have seen? Hey - A third party external DNS server, by default, will not & screws up Exchange to Outlook, on an AD Lan/Wan.
APK
P.S.=> If you guys can show me a workaround for this one, though I am NOT in those conditions anymore (AD lan/wan)? Let us know... thanks! apk
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
I tried to use OpenDNS about a year ago. Ran on it for about 3 weeks. Some of the things were nice (typos on URLs getting fixed, for example), but the overall experience with them as primary DNS was pretty pathetic. OpenDNS response times were awful, taking as long as 3 to 5 seconds to resolve some pretty normal/standard FQDNs (i.e. www.google.com, mail.google.com, bank sites, etc.). At first I thought I something was up with my system, until I traced it back to resolv.conf pointing to OpenDNS. Set things back to real DNS and lo and behold, all my problems over the previous three weeks went away.
I checked them again earlier this year. Exact same problems. This time I only ran on them for a part of a day, as I recognized the problems they were creating immediately.
So, I won't use nor recommend OpenDNS for anyone any longer. Especially in homes or small offices where they have minimal infrastructure. If I had more space, equipment, etc. I might have considered deploying a caching name server for my systems, which might have alleviated some of the problems with OpenDNS, but that was too much work with too little gain.
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
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
dig porttest.dns-oarc.net in txt
At work, I don't get any answer back at all. I'm sure they have things configured in some broken way, can anyone provide a guess as to why I don't get any result at all?
Yeah, I'd just ask there, but it would take days to get back an answer of "please reboot and try again."
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.