DNS Cache Poisoning Vulnerability (2008)

Authored April, 2008
Updated and released Jul 9, 2008

Executive Summary

Dan Kaminsky of IOActive has reported a DNS cache poisoning vulnerability to developers of DNS caching software. The details of this vulnerability will be explained by Kaminsky at the upcoming Black Hat conference in August.

A cache poisoning attack allows unauthorized third parties to inject data into a DNS cache, the injected data may cause rerouting of traffic.

There is no definite solution to the form of cache poisoning described to us by Kaminsky. Only DNSSEC will provide the measures to detect malicious data and prevent cache poisoning.

However in absence of DNSSEC being sufficiently deployed to benefit, methods exist to increase resilience against cache poisoning attacks, and Unbound has these implemented by design.

  • Unbound was designed to use the maximum amount of randomness for query ports and does not need to be upgraded to improve resilience.

  • Unbound has also been designed with a component, called the scrubber, that sanitizes query results and does not add data to the cache it does not trust as being authoritative.

Background

Absent a reference to Dan Kaminsky’s work we refer to other papers where the general principle of port and query ID randomization to mitigate cache poisoning attempts are described.

Recently an article appeared in the Register where a statement that Amit Klein made during the RSA Security conference was quoted as:

I’m not too comfortable with the quality of the solution from the security and predictability standpoint

In 2007 and 2008 Klein has published a number of articles on port and query ID predictability on the website of his company. Work started within the IETF by Hubert and van Mook in 2006 already indicated that making optimal use of the full port range improves cache forgery resilience, and recommends the use of good sources of randomness for the choice of query IDs and ports.

A new strategy to improve the resilience against forgery is the work by Vixie and Dagon, that uses the property that authoritative servers copy the query name, while preserving case, to introduce more entropy matching queries against answers.

Unbound

Unbound is being designed to be a modern, secure and up-to-date name server, that in addition to DNSSEC (the only complete solution to DNS forgery) implements all known mechanisms to increase the resilience to forgery of cache entries.

Unbound version 1.0 has implemented query id and port randomization in the following way.

For each outgoing query both the query-ID and port number are set by routines based on the ARC4 algorithm as implemented in OpenBSD. Arc4random is a pseudo random generator based on ARC4 that addresses the problems, as Klein mentions in one of his papers:

Fortunately, OpenBSD also uses [[…]] the ARC4 algorithm. As such, spoofing responses for the resolver necessitates knowing the UDP source port, predicting the ARC4 algorithm’s next output, or exploiting an implementation bug, none of which is currently known to apply.

To allow for the maximum number of ports to pick from randomly, Unbound uses an advanced strategy. Ports are chosen chosen randomly from the pool of non-allocated ports. Ports can be excluded from this pools by means of a configuration parameter.

There is a small penalty for recursive name servers that will have to do a lot of recursion. This is because there is only a limited set of slots in the socket cache and one may need to wait before one is available. For this penalty there is a compensation by the use of a socket cache which helps the kernel run its select algorithm over open file descriptors.

The mechanisms utilizing case preservation as described by Vixie and Dagon is under development and can be turned on while configuring Unbound 1.0. It should be noted though that the likely hood on false positives, which causes Unbound to ignore an answer thinking it is under attack, is fairly high. There are strategies to deal with these false positives that delay the response time somewhat and are currently under investigation. We plan an implementation of those in once we are satisfied with the behavior.

We believe that the scrubber safeguards against the currently publicly known cache poisoning tactics.