A very serious flaw in the Internet's DNS servers may have been ripe for a significant exploit, though a familiar security researcher might have sounded the alarm just in time. Now, Microsoft and Linux vendors are responding urgently.

In what appears to be a coordinated effort to fix a well known, though still potentially critical vulnerability to the Domain Name System (DNS) protocol, patches are being deployed today for both Windows and Linux, by both Microsoft and Debian, respectively. These patches would enable a long suggested protocol for validating the source of DNS requests.

The move was apparently motivated by a discovery from security researcher Dan Kaminsky, a penetration testing specialist with IOActive, whose warnings in the past have been known to successfully avert major disasters. This afternoon, the US Department of Homeland Security credited Kaminsky with the discovery. This time the subject is one that Kaminsky has discussed in white-hat security briefings since at least 2003: It's called DNS cache poisoning, and it's a sophisticated form of malicious crafting that can result in traffic being routed to the malicious user's choice of addresses.

The real vulnerability is not in Windows or Linux but in BIND, the most widely deployed DNS software everywhere. A security feature in BIND creates a transaction ID for communications between an IP host and a DNS server. Supposedly, that transaction ID is supposed to be randomized using a 15-bit binary number. But the way it's typically deployed, each limitation or option added to the system reduces the number of bits in that random number by one each time, and reduces the number of guesses a malicious script requires to guess the transaction ID by a power of two.

With that accomplished, a malicious user may be able to effectively "poison" the cache of DNS routers with table entries based on appropriately matching transaction IDs, but which point to improper IP addresses.

Apparently, Kaminsky discovered ways in which a certain arrangement of settings could make that transaction ID relatively predictable with a few rolls of the dice. So this morning, Debian issued a trio of security bulletins, one of which advises administrators, as a workaround, to install local BIND 9 query resolvers that implement source port randomization. This gives the malicious crafter a second set of attributes whose value would have to be guessed, and both random elements combined could augment each other's power exponentially.

It is not an easy or an automatic fix for admins to implement, as this morning's security bulletin makes clear.

Microsoft, meanwhile, made good use of this Patch Tuesday to deploy its own workaround package for various builds and configurations of Windows Server dating back to Windows 2000 Service Pack 4 (see this bulletin for a complete list), and Windows XP Professional -- not Windows Vista. It, too, is not automatic -- previous DNS-related patches may have to be manually uninstalled first, in a particular order.

What the new Microsoft workaround will do is implement a greater number of potential sockets for its own implementation of source port randomization, which will substitute for the usual default port number 53. Since Windows Server 2003, the number of available sockets has been limited to 2500, falling somewhere between port 49152 and 65535. This number of sockets can be reset using a System Registry setting listed in this KnowledgeBase article. Once this value is reset and the package installed, randomization can take place starting at port 1024, and extending for however long the new registry setting allows.

"Because attacks against these vulnerabilities all rely on an attacker's ability to predictably spoof traffic," the DHS' US-CERT division reports today, "the implementation of per-query source port randomization in the server presents a practical mitigation against these attacks within the boundaries of the current protocol specification. Randomized source ports can be used to gain approximately 16 additional bits of randomness in the data that an attacker must guess."

This may not be the final workaround for this potentially serious problem, as today's round of suggestions and patches are in response to temporary measures that are being implemented in BIND. A later patch may involve an improvement to how it generates the address of the stub resolver -- the component in the DNS system which forwards queries to the appropriate server, waits for the response, and then passes that response back. Debian's security advisory today notes no such patch for the stub resolver -- a basic GNU library component -- has been made available, though further advisories should be expected for when it is.