BIND 9 and how a security issue demonstrates quality
Recently ISC issued a security warning (CVE-2014-0591) for several BIND versions.
The issue was that BIND 9 detects wrong data while working on NSEC3 records, and because the data is wrong, it opts to terminate itself instead of working with the wrong data (which could expose more serious security issues, esp. when handling DNSSEC data).
Shane Kerr of ISC described this behavior of BIND in the blog post "BIND 9′s Security Record": "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."
ISC's Michael McNally gave some background information on the security issue on the BIND users mailing list. The security issue has been caused by a change in the fundamental operating system library, the "libc". The implementation of the memcpy function has been changed in a recent update of the glibc library used on Linux systems. This change of implementation has triggered the bug to become visible. So far, the same bug has not been seen on other operating systems, or with other libc implementations. However, that does not mean that these systems are safe, just that the security issue does not show (but might still be there).
I'm happy about how BIND 9 handles this issue (terminating instead of ignoring the issue). This way the administrator notices (one hopes) and updates to a fixed version of BIND 9 and as binary installer packages for RedHat, Debian and Solaris from Men&Mice.
What scares me is all the other software out there (open source or commercial) that might be affected by this bug, but does not have the security net that BIND 9 has.
There could be similar security issues lurking in other software products. Stay vigilant! Monitor your servers.
As developers, we should scan our code for this error pattern (memcpy vs. memmove).
