Slashdot Mirror
Bind 4 and 8 Vulnerabilities
eecue writes "The world's most popular DNS package is once again vulnerable. Even the advisory says it's only a matter of time before worms are written.... just like a couple years ago. I guess this is why i run tinydns."
Does TinyDNS support internal and external views? By this I mean, can it return a different IP for the host "foo.my.com" based on what subnet a client is connecting from (e.g., return 192.168.10.11 for all clients in 192.168.* and return 4.3.17.45 for all clients outside of that)? If so, I will switch. If not, I need that function of Bind 9.
MORTAR COMBAT!
All hail djbdns! ... now if we could only convinve djb to loosen some licensing issues.
It was pointed out on the nylug-talk list that the advisory doesn't seem to include any info about whether nominum, paul vixie, or the ISC was notified about the bug.
Does anyone know if ISS did the right thing, or are they being big doo-doo-heads?
-Peter
== Just my opinion(s)
It's funny that they recommend this, yet F.root-servers.net (which is run by the ISC) runs bind 8.3.3.
F is a virtual server made up of multiple systems and runs ISC BIND 8.3.3 as its DNS server.
-----BEGIN GEEK CODE BLOCK----- Version: 3.12 GIT d? s: a-- C++++ UL++++ P++ L+++ E- W++ N o-- K- w--- O- M+ V PS+ P
No, it's secure because no one has ever found a flaw in tinydns. He has a *cash* reward for anyone who can prove that it is flawed. No one has taken then money, in several years of it being offered.
He's a Stallman wannabe. In other words, an asshole.
If he's running BIND9 intead of Berstein's program, he's a moron too.
Used to run Bind9, but BIND seems to be suffering from the Microsoft bloat phenomenon. How many megs do you need for serving up DNS?? The BIND 9 decompressed tar file comes out to 2100+ files at 21MB. If I recall the installation process, it took forever to compile and then loaded the system with a bunch of superfluous directories and files. For more complicated installations with more exotic requirements than I have, maybe I can see using BIND9, but for my wimpy little web server that has maybe two or three A records to its name, there's no point, so I use djbdns.
-R
BIND 9 is slower than BIND 8, because it does a more correct job, but it's not significantly slower for most applications. If you are running a root name server, you will have to buy bigger iron. If you are running a corporate nameserver, you probably won't. For home use, BIND 9 will perform nicely on a 486 (I run it on a Soekris board, for example).
BIND 9 is also not bug-for-bug compatible with BIND 8, so there are some things you can do in BIND 8 that are broken, that you can't do in BIND 9. So upgrading can require some rework if you happen to have unwittingly tripped over those bugs.
On the other hand, BIND 9 is a complete, ground-up rewrite of BIND. It works better, is easier to use, and because of the strict practices that were followed in implementation, is much more reliable.
BIND 9 also supports DNSSEC, which isn't yet widely deployed, but is worth checking out.
(I used to work for the ISC, so you might think I'm biased, but I wasn't involved with the ISC BIND project, so it's more that I got to look on while they did it, and was there to see some of the design work they did to make it more reliable, I know the engineers who did it, and I really think they did a great job.)
OpenBSD severely audited their BIND 4 code-base and it is very secure. This can be ascertained by looking at their errata pages and looking for patches to BIND. There aren't very many at all in the more recent versions.
Sure it's BIND 4, but it's solid and stable, like DNS is supposed to be.
Those who are stuck with BIND 4 for legacy reasons or whatnot are probably best off switching over to a chroot'd configuration - it's all very easy and the functionality is already built in.
You are not alone. This is not normal. None of this is normal.
You say the djbdns "license" is "more restrictive" than Microsoft's "shared source license".
You don't know what you're talking about. Dan Bernstein does not allow you to redistribute FORKS of djbdns. You are very explicitly allowed, in perpetuity, regardless of what Dan says next year, to redistribute djbdns source tarballs with a specific MD5 checksum. Obviously, you are also allowed to publish patches and detailed vulnerability reports. You're simply not allowed to distribute adulterated source code or your own "fixed" binaries.
This is of course a moot point. There has never been a published vulnerability in the qmail or djbdns codebase. qmail is one of the most widely used MTAs on the Internet. The incentive to find vulnerabilities is huge. Bernstein's methodology is correct and his understanding of the Unix secure coding problem is complete.
You say that there hasn't been a djbdns release since last year and offer that as evidence that djbdns is going "stale".
You don't know what you're talking about. There hasn't been a new qmail release in years. qmail remains one of the most popular MTAs on the Internet, contending seriously only with the diminishing Sendmail hegemony and Microsoft's products. There are no new qmail releases because qmail is complete, hasn't had any security problems, and does virtually everything anyone wants an MTA to do. There hasn't been a new djbdns release because djbdns is complete, hasn't had any security problems, and does virtually everything anyone wants a DNS server to do.
Simply calling that a ``DoS attack'' is stretching the truth.
I'm sorry, but what do you think a DoS attack is? The attack mode described would be a classic example, in fact. Whereas, calling it a "security hole" is actively misleading, by omission.
Besides, as you are perfectly well aware, I did not "simply" call it a DoS attack: I stated precisely and concisely what occurred.
The point was to call attention to yet another example of the polemics characteristic of the DJBware camp, and their tendency to shade the truth. In light of which, you have quite a bit of nerve selectively ignoring parts of my accurate characterisation in order to label it "stretching the truth". I'm not surprised, but I am disappointed.
Rick Moen
rick@linuxmafia.com
That's likely to be it's only failure mode in the future - stick a wrapper around it that restarts it when it dies, and you'll be right as rain.
What, like supervise from daemontools?
Nah. It'll never work.
"The world's most popular DNS package is once again vulnerable."
This is the scariest part of the security mentality. Whenever a flaw is discovered everyone freaks and says 'oh, now I'm vulnerable!' until a patch is distributed and 'Phew! Now I'm safe again."
This is not the right way to look at it. The flaw was there for years, and you were vulnerable to everyone who found it before a whitehat did. What's more, you're *still* vulnerable to every flaw that hasn't yet made it to slashdot's pages, but will in coming months and years.
Choosing a platform that reacts quickly to patch discovered flaws means only that you're safer from attacks from those people who read the same sources you do, and quickly move to exploit the published vulnerabilities before you can patch them.
The fact is that it's rarely known how many people discovered a vulnerability before it was made public, and so if you rely on a system that requires frequent hotfixes, however quickly the vendor may react, you are still succeptable to the countless holes that have already been discovered, but not by the good guys.
The morals of this argument are that it's better to use a system that doesn't have as many holes, to one that patches them 'instantly,' and that unless another vulnerability is never discovered in your platform, you're vulnerable to attack today, and always have been.
Kevin Fox