A critical vulnerability in BIND lets attackers send malformed packets that crash the world’s most popular DNS server. All major version of BIND, from 9.1.0 to 9.8.x, 9.9.0 to 9.9.7-P1, and 9.10.0 to 9.10.2-P2, are vulnerable. A patch has been released and anyone running a BIND server should update to a patched version.
Before we head into the long grass on this one, it should be made clear that InterWorx does not use BIND. We use djbdns, which is a smaller, lighter, and less vulnerability-prone DNS server.
BIND has been part of the Internet almost since there was an Internet. Introduced before the web was a gleam in Tim Berners-Lee’s eye, BIND has been a major part of our vital infrastructure for decades.
Unfortunately, that’s part of the problem. Developed in an era with different coding standards and a different security context, BIND is vast, unwieldy, and hard to audit. It is a monolithic piece of software, the developers of which have tried to include every conceivable DNS-related feature, many of which serve no practical purpose in the majority of use cases.
The current vulnerability is caused by an error in the way TKEY queries (which are used by almost no one) are handled. By sending a single malformed packet, an attacker can cause affected versions of BIND to exit. In consequence, anyone with a bit of know-how can send a packet to any of millions of DNS servers and shut them down.
Prompted by the vulnerability, security researcher Robert Graham conducted a preliminary review of BIND. The findings are not comforting.
I could use my “masscan” tool to blanket the Internet with those packets and crash all publicly facing BIND9 DNS servers in about an hour. A single vuln doesn’t mean much, but if you look at the recent BIND9 vulns, you see a pattern forming. BIND9 has lots of problems — problems that critical infrastructure software should not have.
Because BIND is such a critical part of the Internet’s infrastructure, a denial of service vulnerability is extremely serious, especially when one considers the number of BIND servers that are used, but unmaintained.
The habit of creating “kitchen sink” software that implements potentially useful but never-actually-used features should be avoided in public-facing software. It does nothing but increase the chances of coding errors and vulnerabilities. The Heartbleed vulnerability in OpenSSH resulted from a similar approach to development; an error in the little-used heartbeat feature caused a massive panic, and the creation of several leaner OpenSSL alternatives.
BIND is also slow. It was built for a different age and is no longer fit-for-purpose, which is why we choose to use djbdns in Interworx. It contains all of the necessary functionality, is coded and architected according to more modern standards, and it’s fast.
As you can see from our Feature Comparison chart, most other control panels didn’t make the smart choice in this regard.
Image: Flickr/Orin Zebest