LWN.net Logo

Another set of bind vulnerabilities

Here we go again... The Berkeley Internet Domain server (BIND) versions 4 and 8 have a new set of remotely exploitable vulnerabilities. They are well described in this ISS advisory; in short, the problems are:

  • The really nasty one is a buffer overflow in the server's caching code; this one could (and probably will) be used for remote root exploits.

  • The server can be made to terminate (with an assertion failure) when fed a large OPT record with certain kinds of queries.

  • BIND servers can also be made to crash (with a null pointer dereference) when passed information with the right kind of bogus expiration time.

The first vulnerability leaves much of the net open to root exploits, worms, etc. There is no doubt that many servers will not be patched in time, with the result that malware writers will find no shortage of fertile ground for their unpleasant stuff. Business as usual, in other words.

The other result of this set of vulnerabilities is likely to be to force many sites to upgrade, at last, to BIND version 9. That will reduce the diversity of BIND implementations running on the net, thus ensuring that the next vulnerability will affect even more systems. BIND 9 is said to be more secure (having been rewritten with that goal in mind), but there are, beyond doubt, more problems lurking in that body of code. Then we'll get to go through this again.


(Log in to post comments)

Another set of bind vulnerabilities

Posted Nov 14, 2002 8:01 UTC (Thu) by stone (subscriber, #7148) [Link]

BIND Patches for 4&8
http://www.isc.org/products/BIND/patches/

Another set of bind vulnerabilities [Diversity of code]

Posted Nov 14, 2002 17:54 UTC (Thu) by smoogen (subscriber, #97) [Link]

My opinion is that people running 4.x BIND really should really sit back and evaluate why. Of course people have been saying this since 2000 or so and there are still a good number of 4.x BIND boxes out there.

Diversity in code has benefits and problems. When too many people invent their own wheel, you end up with too few people looking at any one implementation. My experience has shown this leads to us vs them thinking and poor code. In the end, you end up with as big a problem when you have 1-2 implementations.

What should be looked at is diversity in coders. When you have people on a team who look at things differently but can get along, you end up with code that is stronger, resilient, etc etc.

Why C?

Posted Nov 14, 2002 22:33 UTC (Thu) by larsga (guest, #2801) [Link]

It's tempting to conclude that the real problem is programming languages that allow you to make this sort of error. There are many languages which offer similar performance to C/C++ without requiring you take off your life jacket. Several of the functional programming languages, Common Lisp, Eiffel, and several others. Java does not have this problem, but has lower performance and is not suitable for everything.

In other words, maybe this will be what finally makes us get rid of these obsolete languages...

Why C?

Posted Nov 15, 2002 4:39 UTC (Fri) by macfisherman (guest, #6018) [Link]

Just because C allows one to shoot themselves in the foot doesn't make it an obsolete language. I believe you answered you own question. Speed.

Why not OCaml?

Posted Nov 15, 2002 7:52 UTC (Fri) by Cato (subscriber, #7643) [Link]

There are high level languages that are as efficient as C but prevent buffer overflows, according to the Great Programming Language shootout, e.g. OCaml. Have a look at http://donkin.org/bin/view/Main/OCamlLanguage for an overview and links to the shootout results - given reasonable weightings for memory, CPU and code length, OCaml comes out top. It has full socket functionality and a good module library so there's no reason why a DNS server couldn't be written in it.

Why C?

Posted Nov 18, 2002 23:32 UTC (Mon) by larsga (guest, #2801) [Link]

As you said, it is not that it is unsafe that makes C obsolete; its obsolesence goes much deeper than that. As for speed, I said explicitly that other languages have comparable speed, and for a DNS server CPU time is not the limiting factor on performance.

Another set of bind vulnerabilities

Posted Nov 15, 2002 16:24 UTC (Fri) by njh (subscriber, #4425) [Link]

The other result of this set of vulnerabilities is likely to be to force many sites to upgrade, at last, to BIND version 9. That will reduce the diversity of BIND implementations running on the net, thus ensuring that the next vulnerability will affect even more systems.

Or, perhaps, rather than upgrading, some sites will switch to DNS software other than BIND, so having a healthy effect on the software diversity of the 'net?

Switching to alternative DNS

Posted Nov 21, 2002 15:57 UTC (Thu) by Baylink (guest, #755) [Link]

Yes, and Dr. Bernstein's package is not the only alternative DNS server.

I won't bother with a list -- everyone here can go Google for 'alternative DNS server' just as easily as me... but I'd be a lot more impressed with the DJB supporters if they'd acknowledge themselves that he and his licenses are controversial, instead of making *us* do it for them.

I run qmail. I rather like it.

But let's be aboveboard, shall we?

Cheers,
-- jra

Copyright © 2002, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds