Re: "djbdns and nxdspecial patch"

On Tue, Apr 27, 2010 at 06:06:51PM +0200, Gerrit Pape wrote:

> Back then I asked around for an exploit implementing the birthday attack
> to actually see how it works out in practice, but got no response.  I
> hacked such an exploit myself, and was able to poison dnscache through a
> fast ethernet link within about 20 minutes using queries for uncached
> SOA records.

Thanks for doing an independent confirmation of the problem. I hadn't
heard that anybody had done so.

> Nevertheless I feel confident with djbdns 1.05 as is.  The exploit ran
> in an ideal environment, numbers change if the dnscache is under load,
> if different records than SOA are used, ...  To me the your.org
> querymerge patch looks too intrusive, and I feel better without patching
> djbdns.  The general cache poisoning vulnerability is well documented,
> also by upstream.

As the author of the patches, I think this is a reasonable approach. The
degree of vulnerability is very dependent on how dnscache is deployed
(i.e., how fast attackers can send spoof packets without being noticed).
And I will be the first to admit that the patches (both the original
qmerge and the followup) have not received a great deal of large-scale
testing (at least not from me), which makes running them a risk in and
of itself.

As I've said before on the list, I am not even running with these
patches; my only dnscache these days is behind a slow link, and it is
hard to trigger a large number of arbitrary lookups. I suspect many
dnscache deployments fit this scenario, and there is no reason for them
to accept the risk of the patch.

> The Debian security team doesn't share my opinion, and asked to fix the
> vulnerability for djbdns to be released with the next stable release of
> Debian.  I tried to convince them with a less intrusive patch that
> exactly targets the exploit described in the your.org paper, "[PATCH]
> dnscache.c: allow a maximum of 20 concurrent outgoing SOA queries",
> which is applied to the dbndns package, not djbdns.  Unfortunately that
> didn't convince them, and I finally stopped trying.  Sometimes there
> simply is no good compromise, be it.  Part of this story can be read
> here
>
>  http://bugs.debian.org/516394

It has been a long time since I looked at the actual issues, so I may be
wrong, but I think Florian Weimer's assertion in that bug report that
you can exploit this without using SOA records is correct. Not caching
SOA makes things easier, but you can randomly switch your query
periodically to avoid cache hits. I don't know if Kevin Day ever
actually performed such a test in his experiments.

-Peff