BIND 9’s Security Record

Introduction

BIND 9 has an image problem.

In fact, BIND of any version has had an image problem since at least the mid-1990’s, when the Internet stopped being a military/educational playground and turned commercial. That’s when security became an issue in a lot of places where people didn’t have to worry about it in the past. That’s when BIND started getting attacked.

BIND 9 was in a lot of ways a direct response to security problems of BIND 4 and BIND 8. And in fact it has done a pretty good job of providing a full-featured and secure DNS server for more than a decade.

Still, system administrators have long memories. I still know people who type “sync;sync” because at one point in their career someone told them that it was useful (it may have even been useful 10 years ago). In the “fool me once, shame on you, fool me… you can’t get fooled again” world of system administration, it is hard for even a product with a very good security record to change perception.

I do not expect to do that with a single article, but I would like to present a bit about how we handle security at ISC, and try to shed some light on the actual story.

Software and Security

Sadly, all non-trivial software has bugs. And all defects are potential security issues, since a bug is the software acting in a way that the developer did not expect.

There are several approaches to dealing with this reality:

1. Reducing the number of defects in the software
2. Improving the way software reacts to defects
3. Using a well-defined and managed process to handle vulnerabilities

ISC uses all three approaches with BIND 9.

As far as reducing defect count, we’ve always had a reasonable software review methodology. In the past few years we’ve adopted unit testing methodology and have recently started using commercial tools to verify protocol compliance and test systems under heavy load. We now have a QA team and are expanding its role.

The manner in which BIND 9 reacts to software bugs is to terminate. While unpleasant for administrators, the idea is to avoid the system running in an invalid state and causing more damage. In BIND 10, we’ve adopted practices and an architecture to minimize this as well.

I think that the process that ISC uses to handle reported and self-discovered vulnerabilities is built on a solid foundation. Let’s delve into it.

ISC’s Security Process

ISC has a published security process, and we take our position as the vendor supporting the most widely-used DNS server very seriously. All security problems are disclosed publicly, along with a detailed description of the problem and a fix, in a timely fashion. Our software engineers, support engineers, and management are experienced and comfortable with this process, and work together to deal with each report as they arrive.

Our process has been significantly refined (one could say that it is now more “formal”) over the past several years. We want to ensure that everyone knows how to evaluate problems, and that we know what to do based on the results of those evaluations. The time to invent - or change - a security process is not during a security incident, especially when feelings are running high. That has happened in the past; mistakes were made, and we make every effort to avoid similar situations now.

Having said that, evaluating a reported security problem will always be more of an art than a science. Some cases are clear - things like crash bugs - but others more complex - like problems that require special zone files to be served authoritatively, for example. This is where ISC’s goal of improving the Internet helps guide our evaluation process.

Review of BIND 9’s Recent Security Record

Let’s look at BIND 9’s recent security history, and perhaps examine similar data for some other open source implementations.

The best place to start is the BIND 9 Security Vulnerability Matrix, also available on the ISC Knowledgebase.

Wow. That’s a lot to take in!

I’ve taken the liberty of following the various links and extracting a few things that I think are relevant to the discussion of BIND 9’s security record.

“When Published” is usually pretty close to the time incidents were reported to ISC. Based on our security policy, if a bug is “in the wild” then we publish a fix ASAP - usually within a day or two. Otherwise, we have a phased disclosure process where we have a little more time to be sure that the fix is both correct and complete, and where we notify high-risk targets and other trusted organizations a few days in advance so that they are not vulnerable when the problem is made public.

In 2013, BIND 9 has had 4 vulnerabilities reported so far. Some observations:

• One problem, number 52, is actually unlikely to have impacted any real-world users, but since it was possible to configure our software in a way that was vulnerable, we treated it with the same severity as other problems. Our policy demands that we do so, and we think it is better for operators, even if it may increase our vulnerability count.
• We introduced one security problem that we know of in 2013, which was caught within a week.
• The other problems were all introduced several years ago.

Okay, let’s look back at last year, 2012:

In 2012 BIND 9 had 6 vulnerabilities, although we actually only released 5 patches since 47 and 48 were handled with the same release.

Some observations:

• One problem, 48, is actually not a crash bug, information leak, or the like. However, based on our security assessment, it reached the level where our policy requires us to publish it as a vulnerability.
• Three of the problems were introduced in the software more than 10 years ago.
• We introduced 1 security problem that we know of in 2012, caught after 5 months.

What does it mean? We have introduced security problems into BIND 9 in the past couple years. We need to get better. On the other hand, most of the defects were introduced long ago - often discovered by researchers or professionals actively probing for problems. The fact that they were undiscovered for so long indicates that they were fairly obscure, and the fact that they were eventually discovered hints at the popularity of BIND 9 and its corresponding value as a target.

Review of Operating System Bugs

It is difficult to defend ISC’s security record without comparing it to other software, but at ISC we consider it bad form to publish direct comparisons of our software with other products. However, I will note that all open source software has some number of reported security vulnerabilities - even djbdns, whose main claim to fame is being secure.

Rather than delving into other DNS software, let’s look at something different - something that everyone reading this will be familiar with: operating systems.

To make our comparisons, I’ve drawn from CVE Details, a great online database of reported vulnerabilities.

Using these data, we can make a quick table of vulnerabilities and compare some popular (and not-so-popular) operating systems:

These data can be interpreted in several ways, depending in large part on both your emotional attachment to any particular product and your feelings about security; how important is functionality versus security, how much risk are you willing to take for performance, and so on.

For example, one could point out that OS X has significantly fewer vulnerabilities than Windows 7. On the other hand, one could argue that OS X is based on FreeBSD, and has several times as many bugs as that operating system.

I think an important takeaway is that systems with many users tends to have more vulnerabilities discovered. This is probably due to two factors:

1. More people are looking for vulnerabilities in systems with lots of users, as these are more interesting targets.
2. Users like feature-rich and complicated systems, which are likely to have bugs. And any bug is a potential security vulnerability, right?

Claiming that one system is secure and another one is insecure is only meaningful for your specific situation. Like benchmarking or interface design, security is both complicated and personal.

Conclusions

We cannot say that BIND 9 has a perfect security record, but BIND 9 is a good piece of software that can be run safely.

ISC takes the security of all of our software very seriously. We feel a deep sense of responsibility to all of our users, and to the Internet community at large. We will continue our efforts, and provide an even more secure BIND 9 in the future!

Shane Kerr