On 8 July 2008, two security vulnerabilities in many Domain Name System (DNS) resolvers discovered by an independent researcher were publicly announced, and vendors of most of the affected software products coordinated the release of multiple server patches for the vulnerability. (Some client-side patches are also available.) The vulnerability, which could potentially allow "spoofing" attacks, is known to affect DNS servers from 79 vendors, as well as other software products that use DNS. Details of the vulnerability and the patches are deliberately being kept vague to make reverse-engineering more difficult, but further information, including a list of affected vendors and products, is available from the United States Computer Emergency Readiness Team (US-CERT) at http://www.kb.cert.org/vuls/id/800113 .

No exploits for these DNS vulnerabilities had been documented at the time of publication. Microsoft and many of the other affected vendors have given them their second-highest severity ranking, because remote code execution (a requirement for highest severity) is not relevant. Nonetheless, this vulnerability could allow transparent rerouting of traffic or routing of traffic sent to internal addresses outside the enterprise perimeter, potentially exposing sensitive information and increasing the risk of further exploits and external "ownership" of internal networks. Moreover, because exploiting this vulnerability does not result in changes to configuration tables in the application, exploits would be difficult to detect.

The patching process includes a change in DNS interaction designed to make it more difficult to "guess" a transaction ID,which is the reason it spans so many implementations. The patch also changes the usual DNS "handshake" and the DNS query protocol involving port/socket usage via port randomization. Firewalls, routers or DNS proxies may require configuration changes in cases where DNS traffic is expected to use a specific port or socket. If the enterprise firewall limits DNS connections to a single port (typically port 53), this restriction must be removed. At the time of publication, conflicts with personal firewalls that use source port firewalling had been reported.

Enterprise security decision-makers:

• Assess whether your DNS servers and DNS resolvers and operating systems are affected, and patch, if necessary, no later than the end of September 2008.
• Scan the network for DNS servers beyond the primary server (for example, in test and development labs or remote geographical locations).
• If any DNS proxies are used, test them to confirm that they can function with the new port behavior required by the patch. If your enterprise tests patches before installation, consider also testing critical components that rely on DNS to function.
• If you are limiting socket ranges for DNS, review the patch notes for your operating systems to determine whether client-side configuration changes are necessary.
• Request a signature update from your intrusion detection system or intrusion prevention system vendor that includes detection of possible exploits using this vulnerability.
• Follow the established best practice of filtering IP addresses at the perimeter to prevent spoofing, such as internal IP addresses coming from external domains.

• "Classifying and Prioritizing Software Vulnerabilities” — Enterprises need a structured approach to classifying and ranking software security vulnerabilities. By John Pescatore
• "Active Directory and DNS Integration” — DNS and Active Directory integration choices continue to present challenges for IT infrastructure deployments. By John Enck, Mark Fabbi and Lawrence Orans

(You may need to sign in or be a Gartner client to access the documents referenced in this First Take.)