[Unbound-users] US-CERT Technical Cyber Security Alert TA08-190B -- Multiple DNS implementations vulnerable to cache poisoning

[Jaap Akkerhuis]

    We will post a more extensive statement later today.
    
It took slightly longer then expected, but here it is.

	jaap

----

DNS Cache Poisoning Vulnerability


NLnet Labs, Unbound development team.
Authored April, 2008
Updated and released Jul 8, 2008



== Executive Summary

Dan Kaminsky of IOActive (http://www.ioactive.com/) has reported a DNS
cache poisoning vulnerability to developers DNS caching software. The
details of this vulnerability will be explained by Kaminsky at the
upcoming Black Hat conference in August (http://blackhat.com/).

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.
  (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-1447).

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


==Background

Absent a reference to Dan Kaminsky 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 Registry[1] 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[2]. 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
Vixie and Dagon[4], 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[5] 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
version 1.1 of Unbound.

Unbound also contains a component, called the scrubber, that prevents
non-authoritative data to enter the cache. We believe that the
scrubber safeguards against the known cache poisoning tactics.

[1] http://www.theregister.co.uk/2008/04/15/dns_cache_poisoning/

[2] http://www.trusteer.com/docs/ contains various articles focused on
    predictability of port and query IDs.

[3] http://tools.ietf.org/html/draft-ietf-dnsext-forgery-resilience

[4] http://tools.ietf.org/id/internet-drafts/draft-vixie-dnsext-dns0x20
    work in progress.

[5] http://unbound.net/documentation/doxygen/random_8c.html