On Tue, Mar 24, 2009 at 08:04:33AM +0100, Soeren Sonnenburg wrote: > Not sure if any of the previous reporters actually read > http://cr.yp.to/djbdns/forgery.html , but it occurs to me as if this > problem is a problem in the current DNS protocol that cannot be > prevented *at all*. However, it can be made significantly harder to > exploit though the definition of hard means here "for send > thousands/millions/billions of packets to exploit the problem." > > Thus I am not sure if this is a bug in djbdns (not more than it is a bug > in telnet that sniffing packets gets you the session in > cleartext) - maybe dnssec/dnscurve http://dnscurve.org/ would help.
The attack under discussion is a bruteforce attack. With current djbdns the attack is more easy than with other implementations that don't send multiple same outgoing queries to a server concurrently, but merge them into a single query. Those multiple indentical outgoing queries enable a birthday attack. dnscache's defense against that is its cache, but the attack Kevin Day describes uses SOA queries which dnscache doesn't cache at all. It's indeed a question of defining 'hard' and 'significantly'. In an nearly ideal environment a proof of concept implementation of the attack through a 10Mb/s link against dnscache succeeds in about 20 minutes, the same attack takes many hours against implementation that merge queries. The numbers change if the dnscache is under load, i.e. there are ordinary clients sending queries to dnscache. My responsibility as a maintainer is to find the balance between upstream's opinion and statements, and what Debian expects from software included in the archive. This is my conclusion and what I suggest to the security team: o Don't apply a patch against the djbdns binary package, but document the fact more prominently. In fact it's already documented for years by upstream, and again detailled in his 'Februar 2009 comments'. o Apply a patch to dbndns, the Debian fork of djbdns, that limits concurrent outgoing SOA queries to 20. I'm of the opinion that this makes the attack significantly harder. If in an nearly ideal environment the attack took 20 minutes through a 10Mb/s link, it takes hours with the patch applied. I've done so with the packages now available in unstable and testing. AFAIK from private discussion, the Debian security team doesn't agree with my assessment. I don't know what their plans are for stable. If a decision is pending for longer, I suggest to get the fix for #518169 into stable soon, I already provided packages to them some time ago. I'm happy to provide packages for stable that included the patch against dbndns from unstable, and the NEWS.Debian entry for djbdns, too, as IMHO that should go into stable. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
