BIND 9 Security Audit

In the aftermath of yesterday’s BIND announcement of seven new CVEs, one of them with a fairly wide impact, BIND users might be wondering why ISC publishes so many security vulnerabilities. While it is undeniable that BIND is mature software, written before today’s level of network abuse was even contemplated, we are actually rather proud of our vigiliance and honesty in looking for vulnerabilities, and acting to address them promptly and transparently. One such effort to proactively look for potential security issues was our 2023 security code audit.

In mid-2023, ISC hired X41 D-Sec, a German code-auditing firm with specific expertise in finding security vulnerabilities, to audit ISC’s BIND 9 source code. We were aware of their earlier audit of NLnet Labs’ Unbound software, so we knew they had some recent exposure to DNS-specific issues. We thought that a team of dedicated auditors would bring fresh eyes and a concentrated focus that might help us significantly improve BIND security. At any rate, we were lucky enough to be able to afford the expense and thought it was worth trying.

The auditors broke the work into two sprints of 30 days each, using two engineers. We began with an online workshop to discuss areas to focus on, and we set up a shared Mattermost instance for quick and easy communications between the auditors and the BIND engineering team. When the auditors were ready to begin each sprint, we asked them to download and analyze the latest development version at the time.

Their methods included both manual inspection and running some automated analyses. They started by looking for the most commonly found types of vulnerabilities in C code, such as memory management problems. Where they found a weakness, they then searched for other instances of a similar pattern or problem. As they said in their report, “The code was inspected for security issues such as integer overflows, OOB reads and writes, hash table degradation, reference counter overflows, use-after-free and double free bugs. Beyond looking for common C level implementation bugs, the team investigated the codebase for bug patterns that might affect BIND 9 specifically.”

Following the manual inspection, the X41 team ran some static analysis and fuzzing. We already run a lot of these automated tools ourselves, so we were not surprised that they didn’t turn up anything significant. The auditors offered to share their scripts with us, should we want to reuse them in the future.

Our experience with the audit was positive: the auditors did not require a lot of help from ISC’s engineering team; we merely shared some ideas about where we thought they might find some issues, and they went off and did whatever they thought made sense. Although we were available to answer questions, they didn’t have many. We were not surprised at the number of issues they raised, although most of them did not rise to the level of something we would rush to address. The issues they did find were real issues, rather than false positives. We were pleased that they created issues in our public-facing GitLab repository for all of the issues they found, and provided excellent documentation to help us see the problems.

Overall the audit reinforced what we already knew, which is that BIND’s security issues are mostly not due to common coding errors, but instead are directly related to the excessive complexity of the DNS standards and therefore the BIND 9 implementation. Most of our CVEs, historically, are vulnerability to distributed denial-of-service (DDOS) attacks by external actors sending some sort of malicious queries that “trick” BIND into performing some complex or resource-intensive processing or replies.

This security audit is only one of the many ways in which we try our best to ensure that BIND 9 is secure and free from vulnerabilities.

Read the full report of the audit here.

Users of BIND who wish to subscribe to our Advance Security Notification (ASN) service are encouraged to contact our sales team.