Welcome to Volume 4, Issue 2 of The Internet Security Conference newsletter, Insight. Insight provides commentaries and educational columns, authored by some of the best minds in the security community.
TISC is about sharing clue. So is this newsletter. We promise to provide something useful each issue. If we don't, flame me.
Enjoy, and be safe,
Dave
DNS is one of the most commonly used and attacked UNIX services on the Internet. This is often and unfairly interpreted as an indictment against the BIND (Berkeley Internet Name Domain) implementation. But DNS attacks have really escalated because close to half the DNS servers installed in production networks are running vulnerable versions of BIND. Recent versions of BIND (9.x) are greatly improved, but versions prior to 8.2.5 had vulnerabilities that attackers used to gain root privileges (NXT), crash the server (NAPTR, fdmax), or deny service (SIG, solinger).
In a group as large and talented as the *NIX development community, some folks will work diligently to fix existing code whereas others will perform a wholesale overhaul under the same project name, and still others will take on a new project entirely. And the incentive to write a more secure DNS server is clearly a significant one, as several such efforts are currently underway. In today's column, Sam Trenholme describes the motivations, objectives, design, and progress he's made in developing one such secure DNS implementation, MaraDNS.
A Domain Name System (DNS) maintains bindings between human-friendly Internet Domain Names and dotted decimal Internet Protocol (IP) Addresses. DNS is a service that almost any intranet or system connected to the internet is required to run. DNS, however, was implemented long before modern security attacks were known; there have been a large number of security problems with some DNS server implementations. An older version of one popular DNS implementation, BIND, was once listed as the number one cause of security compromises. For people wishing to use another DNS server, there is, alas, a paucity of freely-available DNS servers.
To my knowledge, there are only five freely available DNS servers undergoing active development at this time:
This article will focus on the security design of MaraDNS.
MaraDNS should be a secure DNS server.
The reason why I say should be instead of "is" is because I find claims of security very pretentious. There is no way that I nor anyone can guarantee that a piece of code as complex as a recursive DNS server is completely free from security bugs.
What I can assert, however, is that such bugs are very unlikely in MaraDNS, since the design has security checks and balances which minimize the chance of there being a security hazard in the code.
MaraDNS uses a special string library which is resistant to buffer overflows. MaraDNS has a maximum allowed size for every string--any attempt to make a string larger than the maximum allowed size causes the string library to return an error instead of overflowing a buffer. In addition, MaraDNS allocates an extra three bytes for each string object, as a cushion against one-byte buffer overflows. The latter is included because there was a noteworthy case where another program which strived to be secure suffered a remote root exploit due to a one-byte buffer overflow (more information is available from the OpenBSD bugs mailing list archives; look for a posting from December of 2000 with the subject line "Remote hole in ftpd that can lead to root compromise").
MaraDNS also mandates that the server is run as an unprivileged user, and strongly encourages that MaraDNS be run in a chroot() environment. In addition, the DNS cache uses a separate data structure from the local DNS records. This makes it difficult, if not impossible, for the cache to affect the local records. MaraDNS is also protected from a well-known DNS security problem, cache poisoning. The overall design assures that even if there is a security hole in MaraDNS, the possibility of such a security hole allowing the attacker elevated privileges is next to zero.
Two ideas inspired by Dan Bernstein's DjbDNS program have been incorporated into MaraDNS:
MaraDNS also avoids certain known security problems. MaraDNS does not use printf() in a manner which would make format string vulnerabilities possible; MaraDNS does not use any of the potentially dangerous globing functions; and MaraDNS will not have signal handlers until I can figure out a way to make sure that the DNS server is not vulnerable to the known security pitfalls of poor signal handler construction.
I go through the code, and when I find anything which has the possibility of allowing the data to be in an undefined state, I revise the code in question. For example, when I was looking through the code in the 0.8.35 release of MaraDNS; I found a case where the data could potentially become undefined. Even though this was a case where it was impossible to exploit the code in question, I felt it was prudent to update the code--hence the vaguely worded update for the 0.8.99 release of MaraDNS.
MaraDNS also restricts the IP addresses that are allowed to perform recursive (caching) queries, so that administrators running MaraDNS can restrict who uses resources to perform recursive queries. MaraDNS also restricts the IP addresses which are allowed to perform zone transfers, so that people can keep their zone files private. The IP access lists are stored in a format which makes changing access lists for complex intranets easy.
There have been three security problems found with MaraDNS: two fairly major, and one minor security bug.
One major security problem was discovered by Roy Arends, one of the BIND developers, and was caused by the fact the earlier versions of MaraDNS did not check to see whether a given DNS packet was a question or an answer. Since a DNS answer looks like a DNS question, with the exception of a one-bit difference, this bug allowed an attacker to send a spoofed DNS packet which would result in MaraDNS sending an answer to herself (or to another MaraDNS server), which would result in another answer being sent, and so on.
This security glitch passed through because of an overzealous effort on my part to honor the RFC philosophy of "be liberal in what one accepts and conservative in what one sends". Since then, I have gone over the DNS specification to see if there are any other cases where a malformed packet could cause this kind of security problem.
I discovered the other major security problem when performing an audit of the code during the beta test cycle. It involved the decompression code:DNS compression is difficult to implement, and is an easy place to create security holes. In both cases, a denial of service vulnerability was created; however, it was not possible to use MaraDNS to gain elevated privileges through these vulnerabilities.
The minor security problem involved the seed for the pseudo-random number generator. In certain unlikely cases, the pseudo random generator was not as secure as it could have been; this made it easier to send spoofed DNS replies to MaraDNS. These problems have been fixed.
MaraDNS has been a functioning recursive nameserver for over six months, going through a fairly long pre-alpha test cycle, and a five-month alpha test cycle. At the time I am writing this, MaraDNS 0.9.02, the third beta release of MaraDNS with both caching (recursive) and authoritative capabilities, has just been released. MaraDNS is currently frozen--the only updates between now and the upcoming 1.0 release will be documentation updates and bug fixes.
After the 1.0 release of MaraDNS, I have a number of new features planned, including two security features. The features are as follows:
While MaraDNS may eventually have other DNS security features, such as TSIG, I have not received any requests for these features yet, and feel that my development efforts would presently be better spent on commonly requested features, such as SQL support.
If you're curious about DNS security issues in general, or want to know more about DNS alternatives, check out the following resources:
© 2002 - 2006 Core Competence & Mactivity, Inc.