BIND 9.20 Brings Streamlined Core, Some New Features
Today, ISC is proud to release BIND 9.20.0, our newest stable branch.
Read postBIND 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.
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:
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 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.
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.
BIND Vulnerability ID | Date When Published | Version Introduced | Date When Introduced | Time Until Discovery |
---|---|---|---|---|
55 | 2013, Jul 26 | 9.7 | 2010, Feb 16 | 3.5 Years |
54 | 2013, Jun 04 | 9.9.3 | 2013, May 28 | 6 Days |
53 | 2013, Mar 24 | 9.7 | 2010, Feb 16 | 3 Years |
52 | 2013, Jan 24 | 9.8 | 2011, Mar 01 | 22 Months |
“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:
Okay, let’s look back at last year, 2012:
BIND Vulnerability ID | Date When Published | Version Introduced | Date When Introduced | Time Until Discovery |
---|---|---|---|---|
51 | 2012-12-04 | 9.8 | 2011-03-01 | 21 months |
50 | 2012-10-09 | 9.2 | 2001-11-25 | 11 years |
49 | 2012-09-12 | 9.0 | 2000-09-16 | 13 years |
48 | 2012-07-24 | 9.9 | 2012-03-13 | 5 months |
47 | 2012-07-24 | 9.4 | 2007-02-23 | 5 years |
46 | 2012-06-04 | 9.0 | 2000-09-16 | 13 years |
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:
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.
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:
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.
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
What's New from ISC