Bug#518169: Bug#516394: so what is the solution?
* Gerrit Pape: Hi, this seems to be a misunderstanding. I'm asking about the bug http://bugs.debian.org/518169 in djbdns (fix is available since four months), and not the git-core package. On Fri, Jul 10, 2009, Florian Weimer wrote: [something about http://bugs.debian.org/516394] A misunderstanding again, I'm asking about the bug http://bugs.debian.org/518169 The packages I prepared for stable are available since more than four months now, the bug and fix are confirmed and verified. I already asked you back in march, without any response http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518169#15 The fix should finally make it into stable. Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#518169: Bug#516394: so what is the solution?
On sneon 11 July 2009, Gerrit Pape wrote: On Fri, Jul 10, 2009, Florian Weimer wrote: [something about http://bugs.debian.org/516394] A misunderstanding again, I'm asking about the bug http://bugs.debian.org/518169 The packages I prepared for stable are available since more than four months now, the bug and fix are confirmed and verified. I already asked you back in march, without any response http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518169#15 The fix should finally make it into stable. I agree that ideally this should make it into stable quicker; unfortunately this is far from the only security issue, and due to its limited scope we haven't prioritised it earlier, partly also because other issues are known and we prefer to release one update instead of several. As it seems there's not a great chance that the additionally known issues will be fixed soon, so I am now building this update you provided. It will be released when all buildds are there. Thank you for your work on this so far. cheers, Thijs signature.asc Description: This is a digitally signed message part.
Bug#516394: so what is the solution?
On Thu, Jul 02, 2009 at 08:22:04PM +0200, Nico Golde wrote: Hi, * Thijs Kinkhorst th...@debian.org [2009-07-02 20:08]: On tiisdei 30 Juny 2009, Gerrit Pape wrote: While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Hi, I don't understand why the confirmed fix for the reproducible bug with security impact doesn't make it into stable. Can you tell me the reason, or process the packages I prepared? Just like the last time there are build failures on the buildd's which are difficult to resolve. Nico is working on this DSA, perhaps you can contact him on IRC or he can provide more details on the progress. I contacted Gerrit about these build failure and I am still waiting for a reply :/ Hi, this seems to be a misunderstanding. I'm asking about the bug http://bugs.debian.org/518169 in djbdns (fix is available since four months), and not the git-core package. I'd be suprised if this package fails to autobuild on any release architecture: http://niequai.smarden.org/ruGho2e/djbdns_1.05-4+lenny1.diff.gz http://niequai.smarden.org/ruGho2e/djbdns_1.05-4+lenny1.dsc http://niequai.smarden.org/ruGho2e/djbdns_1.05-4+lenny1_all.changes Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: so what is the solution?
Hi, * Gerrit Pape p...@smarden.org [2009-07-03 13:53]: On Thu, Jul 02, 2009 at 08:22:04PM +0200, Nico Golde wrote: Hi, * Thijs Kinkhorst th...@debian.org [2009-07-02 20:08]: On tiisdei 30 Juny 2009, Gerrit Pape wrote: While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Hi, I don't understand why the confirmed fix for the reproducible bug with security impact doesn't make it into stable. Can you tell me the reason, or process the packages I prepared? Just like the last time there are build failures on the buildd's which are difficult to resolve. Nico is working on this DSA, perhaps you can contact him on IRC or he can provide more details on the progress. I contacted Gerrit about these build failure and I am still waiting for a reply :/ Hi, this seems to be a misunderstanding. I'm asking about the bug http://bugs.debian.org/518169 in djbdns (fix is available since four months), and not the git-core package. I'd be suprised if this package fails to autobuild on any release architecture: [...] Sorry for the confusion, given that I am not working on a djbdns update I thought we are talking about git-core. Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpU7yUZ9c9KJ.pgp Description: PGP signature
Bug#516394: so what is the solution?
On tiisdei 30 Juny 2009, Gerrit Pape wrote: While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Hi, I don't understand why the confirmed fix for the reproducible bug with security impact doesn't make it into stable. Can you tell me the reason, or process the packages I prepared? Just like the last time there are build failures on the buildd's which are difficult to resolve. Nico is working on this DSA, perhaps you can contact him on IRC or he can provide more details on the progress. Thijs signature.asc Description: This is a digitally signed message part.
Bug#516394: so what is the solution?
Hi, * Thijs Kinkhorst th...@debian.org [2009-07-02 20:08]: On tiisdei 30 Juny 2009, Gerrit Pape wrote: While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Hi, I don't understand why the confirmed fix for the reproducible bug with security impact doesn't make it into stable. Can you tell me the reason, or process the packages I prepared? Just like the last time there are build failures on the buildd's which are difficult to resolve. Nico is working on this DSA, perhaps you can contact him on IRC or he can provide more details on the progress. I contacted Gerrit about these build failure and I am still waiting for a reply :/ Cheers Nico -- Nico Golde - http://www.ngolde.de - n...@jabber.ccc.de - GPG: 0xA0A0 For security reasons, all text in this mail is double-rot13 encrypted. pgpcLdh3hQXCI.pgp Description: PGP signature
Bug#516394: so what is the solution?
On Wed, Mar 25, 2009 at 04:52:02PM +, Gerrit Pape wrote: On Tue, Mar 24, 2009 at 09:18:24PM +0100, Florian Weimer wrote: * Gerrit Pape: AFAIK from private discussion, the Debian security team doesn't agree with my assessment. I don't know what their plans are for stable. I still hope to get a better patch. While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Hi, I don't understand why the confirmed fix for the reproducible bug with security impact doesn't make it into stable. Can you tell me the reason, or process the packages I prepared? Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: so what is the solution?
On Tue, Mar 24, 2009 at 09:18:24PM +0100, Florian Weimer wrote: * Gerrit Pape: The attack under discussion is a bruteforce attack. No, it's not, it's about 100 times faster than brute force. We're discussing the birthday attack. A birthday attack is a special type of brute force attack. http://www.google.com/search?q=%22birthday+attack%22+type+of+%22brute+force%22 My statement was in response to the suggested analogy to sniffing telnet. 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'. This is incorrect, the old version cannot be reasonably interpreted to mean that a resolver running dnscache can be poisoned within 20 minutes. Since years the docs say 'tens of millions of guesses are adequate with a colliding attack;' With the 15000 packets/s assumption from Day you get to 22 minutes. I'd say it definitely can be 'reasonably interpreted' so. 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. No, it doesn't. Any cache miss will do. There is just a slight inefficiency when you have to switch names to get the next round of cache misses. CVE-2008-4392 doesn't detail such an attack. Can you point to more details, a paper, or an implementation of this attack, that back up the claim? Specifically I doubt the 'slight inefficiency'. AFAIK from private discussion, the Debian security team doesn't agree with my assessment. I don't know what their plans are for stable. I still hope to get a better patch. While we wait for who knows how long, I suggest we get the fix for #518169 into stable; packages still are available through http://niequai.smarden.org/ruGho2e/ Regards, Gerrit. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: so what is the solution?
Package: djbdns Followup-For: Bug #516394 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. -- System Information: Debian Release: squeeze/sid APT prefers stable APT policy: (700, 'stable'), (650, 'testing'), (600, 'unstable'), (500, 'oldstable'), (1, 'experimental') Architecture: i386 (i686) Kernel: Linux 2.6.29-rc8-git-sonne (SMP w/2 CPU cores; PREEMPT) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages djbdns depends on: ii libc6 2.9-6 GNU C Library: Shared libraries Versions of packages djbdns recommends: ii daemontools 1:0.76-3 a collection of tools for managing ii daemontools-run 1:0.76-3 daemontools service supervision ii make 3.81-5 The GNU version of the make util ii ucspi-tcp 1:0.88-2 command-line tools for building TC Versions of packages djbdns suggests: pn dnscache-run none (no description available) -- no debconf information -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: so what is the solution?
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-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#516394: so what is the solution?
* Gerrit Pape: The attack under discussion is a bruteforce attack. No, it's not, it's about 100 times faster than brute force. 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'. This is incorrect, the old version cannot be reasonably interpreted to mean that a resolver running dnscache can be poisoned within 20 minutes. 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. No, it doesn't. Any cache miss will do. There is just a slight inefficiency when you have to switch names to get the next round of cache misses. AFAIK from private discussion, the Debian security team doesn't agree with my assessment. I don't know what their plans are for stable. I still hope to get a better patch. -- To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
