Caught in a BIND

Why it is chronically insecure


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

Limiting Exposure

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.


Other stories you might like

  • Robotics and 5G to spur growth of SoC industry – report
    Big OEMs hogging production and COVID causing supply issues

    The system-on-chip (SoC) side of the semiconductor industry is poised for growth between now and 2026, when it's predicted to be worth $6.85 billion, according to an analyst's report. 

    Chances are good that there's an SoC-powered device within arm's reach of you: the tiny integrated circuits contain everything needed for a basic computer, leading to their proliferation in mobile, IoT and smart devices. 

    The report predicting the growth comes from advisory biz Technavio, which looked at a long list of companies in the SoC market. Vendors it analyzed include Apple, Broadcom, Intel, Nvidia, TSMC, Toshiba, and more. The company predicts that much of the growth between now and 2026 will stem primarily from robotics and 5G. 

    Continue reading
  • Deepfake attacks can easily trick live facial recognition systems online
    Plus: Next PyTorch release will support Apple GPUs so devs can train neural networks on their own laptops

    In brief Miscreants can easily steal someone else's identity by tricking live facial recognition software using deepfakes, according to a new report.

    Sensity AI, a startup focused on tackling identity fraud, carried out a series of pretend attacks. Engineers scanned the image of someone from an ID card, and mapped their likeness onto another person's face. Sensity then tested whether they could breach live facial recognition systems by tricking them into believing the pretend attacker is a real user.

    So-called "liveness tests" try to authenticate identities in real-time, relying on images or video streams from cameras like face recognition used to unlock mobile phones, for example. Nine out of ten vendors failed Sensity's live deepfake attacks.

    Continue reading
  • Lonestar plans to put datacenters in the Moon's lava tubes
    How? Founder tells The Register 'Robots… lots of robots'

    Imagine a future where racks of computer servers hum quietly in darkness below the surface of the Moon.

    Here is where some of the most important data is stored, to be left untouched for as long as can be. The idea sounds like something from science-fiction, but one startup that recently emerged from stealth is trying to turn it into a reality. Lonestar Data Holdings has a unique mission unlike any other cloud provider: to build datacenters on the Moon backing up the world's data.

    "It's inconceivable to me that we are keeping our most precious assets, our knowledge and our data, on Earth, where we're setting off bombs and burning things," Christopher Stott, founder and CEO of Lonestar, told The Register. "We need to put our assets in place off our planet, where we can keep it safe."

    Continue reading

Biting the hand that feeds IT © 1998–2022