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 actually really good. Lets delve into that a bit. ISC's Security Process ---------------------- ISC has a published security process here: https://kb.isc.org/article/AA-00861/0/ISC-Software-Defect-and-Security-Vulnerability-Disclosure-Policy.html 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, with a good turnaround time. Our software engineers, support engineers, and management are all experienced with this process, and work together to deal with each report as they arrive. Our process has been significantly more well-defined (one could say that it is now more "formal") over the past several years. We want to insure that everyone knows how to evaluate problems, and that we know what to do based on that. The time to invent - or change - a security process is *not* during a security incident, when feelings are running high. That *has* happened in the past, and mistakes were made, which is why we avoid that now. Having said that, evaluating a reported security problem will always be something of an art rather than a science. Some cases are clear (crash bugs, for example), but others are not (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. We care! Review of BIND 9 Recent Security Record --------------------------------------- Okay, so having said all of that lets look at the recent history of security in BIND 9, as well as some other open source implementations. I say "recent history", but the age and development style of a particular project of course influence the type and number of bugs that it has. And since as I mentioned, all bugs are potential security problems, these are related. So the best place to start is to look at the BIND 9 Security Vulnerability Matrix, available on the ISC Knowledge Base: https://kb.isc.org/article/AA-00913/0/BIND-9-Security-Vulnerability-Matrix.html Wow. That's a lot to take in! I've taken the liberty of following the various links and extracting out a few things that I think are interesting to the discussion of BIND 9's security record. Number When Published When Introduced Time Until Discovery 55 2013-07-26 9.7 (2010-02-16) 3.5 years 54 2013-06-04 9.9.3 (2013-05-28) 6 days 53 2013-03-26 9.7 (2010-02-16) 3 years 52 2013-01-24 9.8 (2011-03-01) 22 months The "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 - and otherwise we have a phased disclosure process where have a little more time to be sure that the fix is both correct and complete, and where we notify certain "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 is *possible* to configure our software in a way that is vulnerable, we treated it with the same severity as other problems. Our policy demands that, and we think it is better for operators, even if it may increase our count of vulnerabilities. * We did 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, lets look back at last year, 2012: Number When Published 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: * 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 problems 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 - sometimes discovered by researchers or professionals actively probing for problems. The fact that they were undiscovered for so long indicates that they were non-obvious, 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. However, at ISC we consider it bad form to publish direct comparisons of our software with other products. (I will note that all open source software has has security vulnerabilities reported - even djbdns, who's main claim to fame is being secure.) Rather than delving into other DNS software, lets look at something different, but that everyone reading this will be familiar with... operating systems. There is a great database of reported vulnerabilities online here: http://www.cvedetails.com Using this, we can make a quick table of vulnerabilities and compare some popular (and not-so-popular) operating systems: CVSS score 5+ 7+ Windows 7 2013 49 41 2012 39 34 2011 216 201 OS X 2013 18 3 2012 26 8 2011 51 9 Linux 2013 49 14 2012 44 23 2011 37 14 FreeBSD 2013 7 4 2012 9 5 2011 5 5 OpenBSD 2013 0 0 2012 0 0 2011 3 2 These data can be interpreted in several ways, in large part depending on your emotional attachment to any particular product, as well as 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. One important message is that systems with lots of users get 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 ----------- ISC takes the security of all of our software very seriously. We feel a deep sense of responsibility to all of our users, and the Internet community at large. We cannot say that BIND 9 has a perfect security record. But, we *can* say that the security record is not that bad, and that BIND 9 is a good piece of software that can be run safely.