Amit Klein recently released details on DNS server cache poisoning attacks that affect both BIND (Berkeley Internet Name Domain) and Windows DNS servers. It goes to show that every time you think a problem with a well-known protocol or service has been solved, it may not be.

[ RogerGrimes's column is now a blog! Get the latest IT security news from the Security Adviser blog. ]

DNS has been with us since 1983 – nearly as long as the Internet. And although DNS RFCs have come and gone, DNS is still very similar to its original specifications. Certainly it has grown in feature set and complication, but it still has the same underlying security problems it did when it was invented by Paul Mockapetris. The biggest problem is the lack of default authentication. Several security mechanisms have been created for DNS with varying degrees of success (and failure) to solve the authentication problem, but it is still relatively easy to fake a DNS packet to either a DNS server or an unwitting client.

Klein's last find involved two discoveries, both of which allow important parts of a DNS server packet to be forged with trivial effort. The first implementation error involves the DNS UDP source port. Although it should be randomized to prevent forging, it turns out that the source port never changes the whole time the DNS server is up and running. The second, and more important, problem is the trivial predictability of the transaction ID value. Both errors allow DNS server packet information to be predicted and forged.

An attacker can send a malicious Web page link and induce an end-user to click on the link. The clicked link sends off a DNS client query, which can be forged, sending the end-user to a bogus location. DNS has been found vulnerable in the same way before. In fact, Klein laments, "It is saddening to realize that 10-15 years after the dangers of predictable DSN transaction ID were discovered" that DNS software is still susceptible to transaction ID exploitation.

Klein reported his findings to BIND's caretakers, the Internet Software Consortium (ISC), in late May and to Microsoft in April. Both the ISC and Microsoft have released patches or updated software. Thanks are due to Amit Klein for his research and responsible disclosure.

Overall, Microsoft's DNS implementation has been relatively secure. The last major security update to Windows DNS was in Windows 2000 SP2 and SP4, as well as Windows Server 2003 (nearly five years ago). BIND is the most popular version of DNS server software used on the Internet, and its overall security track record has been a bit more active over the years, as one would expect with more popular software. BIND versions 8.x and 9.x have had at least six different vulnerabilities published.

The most secure version of DNS is considered djbdns, named after its author, Dr. Dan J. Bernstein, one of the most prominent voices for security over functionality in computer software. Although djbdns (also known as tinydns for one of its daemons) is not nearly as functional as Windows DNS or BIND, it is run by some of the world's largest companies. Dr. Bernstein claims that more than 1.8 million .com addresses use djbdns. And though Dr. Bernstein has been offering a $500 reward to anyone who can find an error in its 7,000 instructions, there has yet to be a successful claim. Unfortunately, djbdns is built only for Unix and could not be used efficiently to support an Active Directory domain.

Besides making sure your DNS servers are running up-to-date versions of DNS, I think Klein's findings bring up another interesting point. Open source advocates are always touting how open source software allows programming and security bugs to be found faster than with closed source software. It certainly makes sense – there's source code to review, and more eyeballs to review it. But as Klein's research shows, it doesn't make that much of a difference. In the 10 to 15 years that have gone by, nobody (publicly) found the bugs in either the closed source or open source versions inherently faster. Both errors went undetected for more than a decade until one person got interested in the research.

There are dozens of cases just like this, where open source bugs remained unfound for a decade or more, until one lone individual on their own personal quest did some digging. You can look at any of the popular protocols (such as SMTP, SNMP, HTTP, FTP, ASN.1, and so on) and find vulnerabilities that went undiscovered for over a decade. Heck, people are still finding problems in IPv4 packets that have been around for 20-odd years. And as far as I can tell, whether or not the product was open source didn't really play a part in the finding or the fix, albeit the open source fixes are consistently coded faster when the problem is located. What mattered most was a single person (or company) that cared enough to investigate. To the responsible bug disclosure people, I salute you!