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."

Comments

Re:BIND9

[SpaFF]

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.

Upgrading to BIND 9

[mellon]

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.)

Re:AMEN!

[jonadab]

Sendmail likes to _blame_ things on the OS that are really (at least
partly) sendmail's fault. For example, being insecure if /usr is
group-readable. That's just silly; there's nothing inherently
insecure about having /usr be group-readable. (If it were world
writable, that would be something else.) (It was /usr, wasn't
it? It's the thing you have to change in the filesystem to get
sendmail to be secure on OS X.) IMO there's no excuse for sendmail
to blame that on the OS; in the first place, sendmail should be
secure regardless of the filesystem permissions, and in the second
place if it doesn't need to read such places it should run as a user
with fewer permissions (e.g., with its own group like Apache does).
qmail, for all the complaints you can make about its license, at
least takes responsibility for its own vulnerabilities.

Are weaknesses in the OSes _partially_ responsible for some of those
vulnerabilities? Well, sure, but the weakness is exploited through
sendmail and does not have an impact on competing implementations;
that makes it sendmail's problem in my book, and blaming it on the
OS is just a way of shirking responsibility. Do you report the
vulnerability in the OS? Heck, yes, but you also fix your app to
not be exploitable through it. The sendmail people need to drop the
"don't blame sendmail" attitude and write secure software. I know
it's hard being the leading server software in a particular market,
but when openssl can be exploited because of an issue in certain
kernels, they patch openssl. When the openssl issue causes some
Apache installations to be vulnerable, the Apache people release
an advisory. It shouldn't be about placing blame; it should be
about _fixing the problem_. The sendmail people are more interested
in pointing fingers.

Not that there aren't things you _can't_ work around, that have to
be fixed at the OS level. Keeping unauthorized local users out of
the data on a system without filesystem permissions (e.g., Win98),
for example, is not something that can be fixed by the app, at least
not easily. But at some point a line is crossed where the problem
_should_ be fixed in the app. Especially if it's an app that listens
on ports or otherwise receives data from random entities on the net.
sendmail has a long history of being vulnerable -- way worse than
BIND, right up there with IIS and Outlook. And it's going to
continue to be that way for as long as they keep wanting to blame
their issues on the OS.