A stitch in BIND saves nine

This is a story of catastrophe averted. It’s a case study for the value of fuzzing in software development.

Black Duck Cybersecurity Research Center (CyRC) researchers discovered a denial-of-service vulnerability in development branch builds of BIND 9 by Internet Systems Consortium (ISC). Had this vulnerability gone unnoticed in a stable release version, nearly two-thirds of the internet’s name servers would have been vulnerable to a trivial-to-execute denial-of-service attack.

The story of this vulnerability highlights the value of security testing integrated with application development.

About BIND 9

BIND 9 is a suite of software tools related to the Domain Name System (DNS), the internet’s system for mapping alphabetic names to numeric internet protocol (IP) addresses. The vulnerability was located in the named (short for “name daemon”) DNS server implementation contained in BIND 9.

Named is a free software product distributed with most UNIX and Linux platforms. As of 2015, it is the most widely used domain name server software and the de facto standard on UNIX-like operating systems. In September 2020, a survey revealed that BIND 9 was used on 65% of DNS servers.

The vulnerability was discovered in development branch builds of BIND 9, before it was introduced into stable builds and released for widespread mainstream adoption.

TLS support was added into BIND 9 in version 9.17.7, and the related vulnerability was fixed in version 9.17.16. Release notes are here.

Consequences

Had this vulnerability survived into a production release, the consequences would be dire for any organization using named.

In such a scenario, any server could be crashed with a single message if the right features in named were enabled. This would cause severe networking disruptions in the area of the affected servers.

Finding vulnerabilities with fuzzing

Black Duck researchers found this vulnerability using fuzzing, a negative testing technique in which deliberately malformed inputs are delivered to target software. When a failure occurs, a vulnerability has been located. In this case, the fuzzer delivered a DNS request over TLS with an invalid opcode, and named crashed with an assertion error.

While it is possible for developers to write negative unit tests, the process is slow and tedious. An automated fuzzer can create and deliver thousands or millions of badly formed inputs to thoroughly exercise the target software.

The fuzzer used by Black Duck researchers was Defensics®, which creates high-quality test cases by using generational (or model-based) fuzzing. It knows all the details of valid inputs, which means it can create fuzz test cases that are nearly correct, but anomalized in specific ways. The resulting test cases push the target software into specific states and exercise many code pathways.

As with any type of security testing, keeping up with the latest developments is important in fuzzing. DNS over TLS is new and not widely implemented or deployed. Updating our DNS test suite to support DNS over TLS shows how staying current is important, and how fuzzing can help improve the security of an entire ecosystem.

Software gets fuzzed one way or another. That is, when applications are released and deployed in the world, they will receive unexpected and malformed inputs, either by accident or as an attack. Proactive fuzzing during application development results in a hardened, more resilient application that is less risky to deploy and operate.

Security in application development

Fuzzing is just one of the security testing tools that should be part of application development. Static analysis tools read through source code to look for issues. Software composition analysis (SCA) tools help development teams manage their use of open source components, both in terms of known vulnerabilities and licensing.

Interactive application security testing (IAST) tools observe running web applications and APIs to detect vulnerabilities. Other types of testing can be appropriate, depending on the type of application.

But it’s not just about tools. Even before any code is written, design-time activities like threat modeling help flush out flaws that could otherwise become serious trouble. A comprehensive, proactive approach to application security is the only way to minimize risk and drive efficiency. A secure software development life cycle (SSDLC) incorporates security at every phase of software development, from design through implementation, testing, deployment, and maintenance.

Acknowledgements

Ville Heikkilä from the Black Duck Cybersecurity Research Center (CyRC) in Oulu, Finland, discovered these weaknesses with the Defensics DNS server test suite and newly added DNS-over-TLS support.

The ISC team was responsive and quick to implement a fix. We very much appreciate their cooperation.