- By Shawn Routhier on November 29, 2013
On November 29th ISC’s DHCP4 will turn 18.
The first code for the DHCP project was committed to the source repository by Ted Lemon on 1995-11-29. Over the years, our contributors have committed over 9,500 change, covering everything from small bug fixes to major enhancements. Today, our DHCP code supports clients, relays and servers for both DHCPv4 and DHCPv6.
Looking forward, our next feature release, DHCP 4.3.0, will be coming out soon. Our focus is DHCPv6 uplift: we are enhancing the DHCPv6 code by adding popular DHCPv4 features not currently available in DHCPv6.
ISC is also moving forward with a new generation of DHCP code. Codenamed Kea, this project is a complete re-write of the DHCP code base to bring it more in-line with current hardware and software capabilities.
On a personal note, as the current maintainer of ISC’s DHCP4 code base, I’d like to extend a big thank you to all of the previous maintainers and committers that have helped make the code what it is. The following people are listed in the repository log as having made contributions to ISC DHCP over the past eighteen years:
Mark Andrews, James Brister, Ben Cottrell, Francis Dupont, Michael Graff, David Hankins, Evan Hunt, Shane Kerr, Ted Lemon, Stephen Morris, Tomasz Mrugalski, Murray, Damien Neil, Jeremy Reed, and Paul Selkirk.
I’d also like to thank all the people that have and continue to use DHCP. It is wonderful to know that code I work on helps people connect to the Internet every day.
- By Shane Kerr on November 4, 2013
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:
- Reducing the number of defects in the software
- Improving the way software reacts to defects
- 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 Knowledge Base.
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 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 is 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:
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.
- 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, who’s 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.
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:
- More people are looking for vulnerabilities in systems with lots of users, as these are more interesting targets.
- 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.
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 the Internet community at large. We will continue our efforts, and provide an even more secure BIND 9 in the future!
- By Laura Hendriksen on October 31, 2013
Who knew? We sure didn’t, and that’s why we’re asking. ISC has been providing BIND and ISC DHCP software for over 15 years now. Publicly-available sources put our market share at over 80%, meaning our users come from a wide variety of industries and skill levels, but all depend on BIND. In order to gain a better understanding of how our users obtain and use our software – namely, BIND and ISC DHCP – we recently created an optional survey at the time of software download. We’ve collected almost 200 responses so far and look forward to many more. There’s a cool t-shirt in it for folks that complete the full survey.
Since we’re asking our users to share information with us, we’re returning the favor. Some of the more interesting data are included in this post. If your responses would be similar, please share. If not, don’t go unrepresented. Add your profile data. Ultimately, it’s all about you.
- 47% are running BIND 9.9
- Over 13% of the survey respondents came to the site to download our next generation version, code named ‘BIND 10’
- Almost 60% of folks rely on the ISC website for information on new releases, while only 29% subscribe to our mailing lists
- 40% of responders upgrade their software every 6 months, but 10% stated they upgrade once every 3-5 years
- Only 30% are running DNSSEC but 50% plan to do so in the future
- Over 45% have implemented IPv6 and about the same number plan to do so
- By Adib Behjat on October 10, 2013
Internet Systems Consortium’s (ISC) Board of Directors named Jeff Osborn as Executive Director with the explicit goal of ensuring production-‐ quality, fully featured nameserver software is available as open source, with no financial barriers to its use. Osborn will also serve as President of DNSco, ISC’s commercial subsidiary.
“I am both thrilled and humbled to be trusted with the task of leading ISC,” said Osborn. “I am proud to contribute to ISC’s storied history of commitment to the global Internet community, and I look forward to working closely with our many and varied stakeholders. DNSco also has a key role to play as the primary funding vehicle for our public benefit work, and has an opportunity to address the growing threats to the DNS from a business support perspective.”
ISC and DNSco continue to develop, maintain and distribute BIND and ISC DHCP as open source software. ISC makes essential infrastructure software available; DNSco offers professional support subscriptions for ground-‐level business continuity planning. DNSco is a commercial business tasked with generating revenue to sustain both itself and its parent company.
Find Jeff Osborn on LinkedIn at http://www.linkedin.com/pub/jeff-‐osborn/0/651/880
- By Michael McNally on September 27, 2013
Happy 30th birthday to the GNU project!
According to their announcement commemorating the event on the GNU.org site, September 27th, 1983 was the day that Richard Stallman first announced the GNU project to the public.
Today the open source software movement that GNU pioneered is vibrant, thriving, and global. It counts among its members a multitude of individuals and project groups motivated by an amazing variety of values and goals. Millions every day use open source software directly and innovation and competition from open source have spurred improvement even in projects that don’t share the open source philosophy.
At ISC we’re proud to be part of the open source movement that the GNU Project trailblazed. We’d like to salute our colleagues (and respected elder siblings) at GNU and congratulate them on their past 30 years of remarkable achievement. Well done, GNU, and thank you for all that you have done to make the world a better place.