How did one of the Internet's most ubiquitous software packages grow up to be chronically insecure? History offers a lesson, says Jon Lasser.
Weinberg's second law, a decades-old programmers' joke, states, "If builders built buildings the way programmers wrote programs, then the first woodpecker that came along would destroy civilization."
There may be no better example of that principal in action than the BIND name server software.
The most recent misadventure to befall the ubiquitous program came to light last week -- when a new exploitable vulnerability in BIND 4 and BIND 8 was announced.
This is by no means the first security hole to be found in BIND over the years. The product of an earlier era in the Internet's history, BIND's troubled past has much to do with its roots. It began as a university project, and grew with the needs of its developers. Like Sendmail -- another fount of security holes, before it was completely rewritten -- BIND started small, but its mandate kept growing and the tool was expanded to fill the need.
Back in 1983, when the DNS system was first deployed, nobody expected to stop everything to fix bugs or rearchitect from the ground up: the whole Internet was a research project. By the time everyone realized that the network itself was no longer a laboratory, it was too late -- the code was everywhere, in use on production systems.
By today's standards, BIND 4 was poorly-written. And despite its adoption of a new file format, BIND 8 is really based heavily on the old BIND 4 code. It's a new facade on a collapsing old building. The next time we build a bustling metropolis, we should hire different architects.
The Internet Software Consortium, BIND's developers, may have hired those better architects for BIND Version 9 -- the first complete rewrite of the program from the ground up. It's not vulnerable to the latest exploit. It's also been out for more than two years, and though still dogged by some reports of instability when heavily loaded, in my experience it seems more stable and behaves more correctly than do the older versions.
The ISC acknowledges this, and recommends that everyone switch to BIND 9. But people are loathe to relocate when the old house seems fine. (I say that we should just condemn the old buildings, but few people would agree with me on that point.)
But many users are stuck with vendor-provided configurations of BIND 8, or even BIND 4. Vendors like the old versions because the old software is better understood, and upgrading to a new version is not without its challenges.
BIND 4's configuration syntax is completely different from the syntax used in versions eight and nine, so users with a large number of DNS records find it difficult to convert from version four.
And though BIND 8 uses the same configuration file syntax as BIND 9, the earlier version is much less strict about what it will accept. So transitioning from BIND 8 to 9 is painful too, and typically requires correcting tens if not hundreds of errors in zone files before BIND 9 will even start up and serve DNS information.
But as the latest hole should remind us, upgrading is worth the effort. In addition to being more secure, BIND 9 includes named-checkconf and named-checkzone, which allow you to verify that your configuration file syntax is correct. Automated data validation tools like these allow us to build more reliable and robust systems and reduce the cost of proper system architecture.
If you're saddled with an old version, take heart. With the latest security holes, the programs are vulnerable only when acting as recursive name servers. In brief, this means that the holes only affect servers that can look up any address on the Internet. Your name servers should not respond to such requests from external addresses anyway: to do so opens the door to DNS cache poisoning attacks. Your name servers should respond only to authoritative requests from outside your network, and allow recursion only within the network.
Sadly, most BIND configurations will allow recursion from any address -- that's the default configuration of BIND, another situation that the Internet Software Consortium should resolve.
When the Internet was designed, nobody imagined swarms of thousands of six-foot-tall jet-black stealth woodpeckers. Today they're here, and it's time our architects took the woodpeckers into account.
© 2002 Security Focus. All rights reserved
Jon Lasser is the author of Think Unix (2000, Que), an introduction to Linux and Unix for power users. Jon has been involved with Linux and Unix since 1993 and is project coordinator for Bastille Linux, a security hardening package for various Linux distributions. He is a computer security consultant in Baltimore, MD.