ISC has released BIND 8.2.3 with another set of security fixes. This is the third or fourth BIND release this past year that I have written about, depending on how you count. The catalogue of BIND advisories now reads as its own small genre.
This is going to be a short post. The new advisory is mostly more of the same; the patches are straightforward to apply; the structural lessons have not changed.
What is in 8.2.3
The advisory covers several issues. The two that matter most for operators:
A vulnerability in the SIG record handling that allows a remote attacker to crash a recursive resolver by sending a specially-crafted DNS response. The crash is reproducible; the consequence is that the resolver becomes unavailable. Not code execution, but reliable denial of service.
A vulnerability in the NXT record handling — yes, the same component as the bug last summer, but a different specific issue. This one is also a denial-of-service rather than a code-execution path. Better than last summer's, but still serious.
Both issues are pre-authentication; both can be triggered by traffic from any source.
There are also a handful of non-security improvements — better handling of IPv6 records, performance improvements in zone loading, some bug fixes in zone transfers. The non-security stuff is welcome but is not the reason to upgrade urgently.
Why I am not writing more
The specific technical detail of each BIND advisory is no longer the most interesting thing about them. The pattern is.
In the eighteen months since I first wrote about BIND advisories, there have been at least seven distinct security issues published. The advisories follow a roughly predictable shape: a memory-corruption bug or a denial-of-service issue is found in some part of the record-handling code; ISC patches it; operators are asked to upgrade.
The codebase is being audited. The auditing is finding bugs. The bugs are being patched. This is correct work and is a sign of a mature security process. It is also, by quiet implication, a sign that the underlying codebase has more bugs to find.
The structural problem
BIND is a piece of code that has been written and maintained, in C, for nearly two decades. It serves an immense fraction of the world's DNS queries. It is on the critical path for almost any other internet service.
The codebase has the shape of every other long-lived C codebase: complex memory management, many places where input becomes a structure that is parsed and acted on, accumulated technical debt from earlier design decisions. The auditing process is finding bugs because the codebase is the product of an era when these classes of bug were not on the development radar.
This is not unique to BIND. Sendmail, wu-ftpd, Apache, the various SUID utilities — all in similar shape. The 1990s have produced a substrate of widely-deployed C code that is being progressively cleaned up at a rate that is meaningfully slower than the rate at which new bugs are being discovered.
The long-term answer is structural. Either the code gets rewritten in safer languages (a multi-decade project), or the C code is fortified with mitigations (compiler-level guards, kernel-level protections, runtime sandboxing). Both are happening. Neither is happening fast enough that any individual operator can stop tracking advisories.
What I am doing
For my own infrastructure, the response is mechanical at this point:
- Read the advisory.
- Confirm I am running an affected version (I am — 8.2.2-P5).
- Build 8.2.3 from source on the test machine.
- Verify it starts cleanly with my current configuration.
- Deploy to production and restart
named. - Verify with
dig version.bind chaos txtthat the running version is 8.2.3. - Update my structured-log monitoring to confirm the new version is the only one running.
Total time: about an hour, assuming nothing breaks. I have done this enough times now that the procedure is automatic.
For the friends I support, I send a short email with the advisory link and a copy of my own upgrade procedure. Most of them upgrade within a week. One reliable late adopter usually waits until I poke them; he then upgrades within a day.
Where this leaves the longer story
The steady drumbeat of BIND advisories will continue. ISC will keep auditing. New bugs will keep being found. The operator's task is to stay current and to not assume that being current means being safe.
The deeper question — what to do about a critical infrastructure component built on an inherently buggy substrate — is one I do not have an answer to at the operator scale. The structural answer requires changes in the project itself, in the programming-language ecosystem, in the deployment patterns. None of those are mine to make.
What I can do is contribute small amounts where I can: reading advisories carefully, being responsive when I find issues, pointing the next generation of practitioners at the structural problem rather than just the immediate symptoms. The blog has, perhaps surprisingly, become part of that contribution.
More in the new year on whatever the next BIND advisory turns out to be. I will keep writing them up briefly because operators reading them deserve a short summary, even though there is little new to say each time.
Next post will be on something more interesting. The Linux 2.4 development snapshot has been worth reading.