Slashdot Mirror
DNS Cache Poisoning Update
dhammabum writes "Todays SANS internet storm handler has put up an excellent update of the DNS poisoning vulnerability currently doing the rounds. The main points are that only Windows DNS servers are vulnerable (degrees of vulnerability depending on patch level), provided you are not running an ancient version of bind. Also bind4 and bind8 do not clean poisoned caches if they receive them from a poisoned Windows DNS server but bind9 does."
"If you don't like windows don't use it"
Or then telling me, when they find out I don't use it, that I've somehow forfeited the right to complain about it anymore; or trying to hold Microsoft blameless for their security holes because the people who run Microsoft software do so by "choice" so its the users own fault, and they are just hurting themselves.
But then I keep finding that despite not using Microsoft software, I get negatively impacted by it anyway. Because the Code Red slaves on the network are bombarding me with a constant light DOS looking for that index server or whatever. Because I get bombarded with email viruses and spam from zombie PCs which, while harmless to me, make my email account less useful. Because my DNS server is running Windows.
Lovely.
So, look at this. I am being materially negatively impacted by a company whose products I don't even buy. How, exactly, is the invisible hand of the market going to help with this?
If we were really dealing with an ideal 'invisible hand' at work, the smart, money-saving people would leave 'the' internet and start their own security-required network, which would quickly become the larger network and regain the distinction as 'the' internet, thereby forcing everyone on the 'old' internet to get secure in order to join up. But that doesn't happen, does it. Sadly, the invisible hand is only good at two things, truly open marketplaces, and giving you the finger.
so much more reliable than BIND
I have never, not once, ever had BIND fail. I doubt I'm the best DNS admin anywhere, so I imagine it works well for a lot of other people as well.
Why am I putting my users at risk?
Because my secondary DNS servers, provided by my registrar, are out of my control. I can't install rsync on them to support the functionality that Dan left out of djbdns.
If you're a DNS admin, don't waste your time with bugs from the 1990's.
I'll agree with that. Upgrade to the most recent version of BIND and get on with life. OpenBSD's support of that policy is a pretty strong endorsement.
Dewey, what part of this looks like authorities should be involved?
Blaming it on MS is akin to blaming Ford if you forget to lock the door on your car.
Nah, It'd be like blaming Ford if they sold all cars without oil in them and had, on page 545 of the 2000 page manual, directions to add oil before use.
Sure, they tell you and it is documented, but you shouldn't have the server install insecurely by default. The default should be secure, and then you need to enable the services you need. Less user friendly, more secure - that is why it isn't adopted by MS. They made a conscious decision to make it insecure (but easier to use). That is why MS bashing is justified.
Learn to love Alaska
First, djbdns isn't Free Software, which means that a lot of us won't touch it with a ten-foot pole. See the recent BitKeeper debacle for reasons why that's the pragmatic rationale and not just an ideological decision.
There is a HUGE difference between BitKeeper and DJB's copyrighted software. DJB's software is distributed as source code without any "license". This means that you will always have the option of using, modifying and distributing patches for any released version. He can't suddenly take the software away from you.
I can't install rsync on them to support the functionality that Dan left out of djbdns.
djbdns includes an AXFR server.
In my experience, software issues occur for one of two reasons:
(1) "Broken" code:.....
(2) Bad communication / misuse of code:....
You left one out:
(0) Bad Design: The code does everything you intended it to do and the users are using it properly, but you didn't think of all the possible states in which the code could find itself and decide what to do about them.
This is often lumped in with (1), but shouldn't be IMHO. It's one reason I think that comments in code are valuable (as are formal design documents) since it forces the person, or people doing the design and coding to restate their intentions in at least a couple of different ways.
I have written and worked with well written specs and they tend to reduce the number of pure coding errors by leaving less to the imagination of the coder. Well written specs can still fail to account for all possibilities however and that's a good reason to have meaningful design discussions (rather than the formally mandated ones that people attend these days in body but not mind).
There are many people today who think of themselves as ace coders. The world would do well to have more people who are design experts who don't practice coding at all. The two disciplines complement one another well.
Two words: dynamic DNS.
There are a lot of little single-entry updates to some of our zones, and IXFR transmits only the changed entries to the slaves.
How come your zone files are so big, and how come you network is too slow to transfer entire zone files?
Reverse that: even though our zone files aren't terribly big, why would we want to transfer the whole thing each time? It's the difference between sending a patch file instead source tarball for every update. Isn't efficiency supposed to be a good thing, even when it's not absolutely necessary?
Dewey, what part of this looks like authorities should be involved?
Time to stop the DJB fanboy FUD.
BIND 9 is a complete rewrite of BIND. It has none of the security issues that older versions of BIND has. In particular, the best security attack against BIND 9 results in a denial-of-service; any such DOS attacks have been patched by the ISC.
BIND 9 also has a number of security features DjbDNS doesn't have. Starting with DNSSEC. Also, it has full support for DNS-over-TCP, which stops a certain attack that DjbDNS is not capable of stopping.
Stop listening to the DJB fanboy FUD and start paying attention to the facts. If you don't mind the fairly large footprint BIND 9 has, it is a completely free, secure, and excellent solution to your DNS needs. If BIND 9 is too big for you, there are other DNS solutions that are lightweight and aren't DjbDNS.
One fact DJB fanboys won't tell you is that DJBware is not free software.
To give the explanation of DNS poisoning in a slightly different way (based on what I know of BIND, DNS and from the SANS pages from earlier)....
I'll assume everyone's up on how a cache works. DNS poisoning is possible on DNS caches which aren't suitably paranoid about how data gets into the cache.
Basically, a server that is trying to poison a cache sends additional records with its answer, and those records are unrelated to the question.
So, you ask "What is the address of bogusserver.badguy.com?". In the answer you get back, it says something like this:
(For those that don't know, a DNS name ending with '.' is considered an absolute name; the "root" of the DNS is noted with a single '.'.)
That answer above gives the host address of bogusserver.badguy.com (the "A" record) and a nameserver address for all of "com" (the "NS" record). (These examples are IPv4 only, that's effectively what the "IN" means.)
So, a poison-resistant DNS will reject all the parts of the answer that do not match the question. "What, com.? I asked about bogusserver.badguy.com.! Forget this bit about com.!"
One that is susceptible to poisoning will accept the updated record for "com." also, and enter it into the cache. Since it didn't need to know about the nameserver for com., the only part that matters is that it is caching the wrong nameserver address. Now, anyone who asks that DNS cache for the name server address for ALL of "com." gets the address injected by the nameserver for bogusserver.badguy.com. At that point, that nameserver can tell your client whatever it wants. All future lookups for "com.", until the cache expires (usually 2-7 days), will use the malicious server.
Some servers make this worse by invalidating all entries for a domain when the nameserver entry is updated for that domain--forcing a query of the malicious server for sites that are used often (and hence are in the cache).
This attack DOES require that someone requests a name that will trigger a query of a malicious nameserver. This is pretty easy, though; send mail that will bounce with an envelope-from address in the malicious domain.
He ducks! He dodges! He backpedals!
Dunno how many complaints there were, but I don't recall any great hue-and-cry. Do you? Can you link it? Don't forget, pre-Win2k/SP3 versions were securable with a single setting, as I said before.