Many crackers are not particularly skilled and simply follow security announcements to learn of new vulnerabilities while relying on the fact that many administrators are slow to patch even well-known problems. In the case of BIND vulnerabilities, the attack frequency appears to peak a couple of months after the initial announcement and then taper off for almost a year after that, indicating that many sites are taking that long to make the necessary updates. Even worse, the Internet Software Consortium (ISC), the organization that manages BIND, reports that versions as old as BIND 4 (BIND 9 is current) are still widely used despite the fact that ISC no longer supports them. Because BIND is normally run on a superuser (“root”) account, this access would allow a cracker complete control over the system. # Transaction signature handling code (TSIG) signed queries have a buffer overflow problem in versions 8.2, 8.2-P1, 8.2.1, 8.2.2-P1, 8.2.2-P2, 8.2.2-P3, 8.2.2-P4, 8.2.2-P5, 8.2.2-P6, 8.2.2-P7, and all 8.2.3-betas (based on ISC information). This is an extremely important vulnerability, which, again, can give attackers full access to a system. According to the ISC, there is no workaround for this, and therefore, an upgrade is the only fix. See Vulnerability Note VU#196945. * The nslookupComplain() function contains a buffer overflow vulnerability in BIND 4 versions 4.9.3, 4.9.4, 4.9.5, 4.9.5-P1, 4.9.6, 4.9.7, and possibly earlier versions of BIND 4.9.x and BIND 4.9 (based on ISC information). Again, ISC says there is no workaround. Attackers could gain access to the system or cause stack corruption. See Vulnerability Note VU#572183. * Another nslookupComplain() problem is the input validation, which was fixed by ISC in release BIND 4.9.5-P1. CERT states that many third-party distributors of BIND 4 have not made the upgrade, so all BIND 4 versions are suspect. There is no workaround, and an upgrade is also required to fix this problem. See Vulnerability Note VU#868916. * BIND 4.9x and 8.2x have a less critical vulnerability that can expose information contained in the program stack. Just how important this is depends in large part on what information is in the stack, which sometimes includes important environment variables that could be misused by crackers. See Vulnerability Note VU#325431.