[security]: Rapid DNS Poisoning in dnscache

Debian Bug report logs - #516394
[security]: Rapid DNS Poisoning in dnscache

Toggle useless messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: "Hideki Yamane \(Debian-JP\)" <henrich@debian.or.jp>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: [security]: Rapid DNS Poisoning in dnscache

Date: Sat, 21 Feb 2009 16:20:14 +0900

Package: djbdns
Severity: critical
Tags: security patch
Justification: breaks the whole system

Hi,

 I've found an article about DNS Cache poisoing for dnscache,
 and patch is available at his site, see http://www.your.org/dnscache/
 patches are "freely distributed", so we can apply those.

 It was assigned as CVE-2008-4392
 http://web.nvd.nist.gov/view/vuln/detail;jsessionid=7afcdf51e3392babb80f256628c4?execution=e1s1

 Please check above sites and release updated package.

 Thanks.

-- 
Regards,

 Hideki Yamane   henrich @ debian.or.lp
 Debian Maintainer/Translator

Message #10 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: "Hideki Yamane \(Debian-JP\)" <henrich@debian.or.jp>, 516394@bugs.debian.org

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Thu, 5 Mar 2009 15:40:43 +0000

tags 516394 - patch
quit

On Sat, Feb 21, 2009 at 04:20:14PM +0900, Hideki Yamane (Debian-JP) wrote:
>  I've found an article about DNS Cache poisoing for dnscache,
>  and patch is available at his site, see http://www.your.org/dnscache/
>  patches are "freely distributed", so we can apply those.
> 
>  It was assigned as CVE-2008-4392

Hi, unfortunately the patch has its problems
 http://thread.gmane.org/gmane.network.djbdns/13705/focus=13868

See
 http://cr.yp.to/djbdns/forgery.html
for upstream's February 2009 comments on this issue.

Regards, Gerrit.

Message #17 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: 516394@bugs.debian.org

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Tue, 17 Mar 2009 10:52:49 +0000

$ zcat /usr/share/doc/djbdns/NEWS.Debian.gz |head
djbdns (1:1.05-6) unstable; urgency=medium

  CVE-2008-4392 reports 'Rapid DNS Poisoning in dnscache', the dnscache
  program included in djbdns-1.05.  Upstream's comments on this can be
  read in http://cr.yp.to/djbdns/forgery.html

  The dbndns package, the Debian fork of djbdns, includes a patch that
  limits concurrent outgoing SOA queries to 20 instead 200 (MAXUDP) to
  make birthday attacks more difficult.

$ zcat /usr/share/doc/djbdns/changelog.Debian.gz |head
djbdns (1:1.05-6) unstable; urgency=medium

  * dbndns/diff/0004-dnscache.c-allow-a-maximum-of-20-concurrent...diff:
    new; dnscache.c: allow a maximum of 20 concurrent outgoing SOA
    queries (#516394).
  * debian/djbdns.NEWS.Debian: talk about the patch 0004-dnscache.c...
    being applied to the dbndns package.
  * debian/dnscache-run.postinst: restart dnscache on package upgrade.
  * debian/dbndns.README.Debian: document that patches 0003-...diff,
    0004-...dif are applied to dbndns.
$ 

Message #22 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: 516394@bugs.debian.org

Cc: control@bugs.debian.org

Subject: SOA change does not fix poisoning

Date: Wed, 18 Mar 2009 07:39:40 +0100

found 516394 1:1.05-6 
thanks

The SOA-related changes do not make the attack significantly harder,
so the issue is still present.

Message #31 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Soeren Sonnenburg <sonne@debian.org>

To: Debian Bug Tracking System <516394@bugs.debian.org>

Subject: so what is the solution?

Date: Tue, 24 Mar 2009 08:04:33 +0100

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

Message #36 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: Soeren Sonnenburg <bugreports@nn7.de>, 516394@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Tue, 24 Mar 2009 10:30:26 +0000

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.

Message #41 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Soeren Sonnenburg <bugreports@nn7.de>

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Tue, 24 Mar 2009 21:18:24 +0100

* 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.

Message #46 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: Florian Weimer <fw@deneb.enyo.de>, 516394@bugs.debian.org

Cc: Soeren Sonnenburg <bugreports@nn7.de>, 518169@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Wed, 25 Mar 2009 16:52:02 +0000

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.

Message #51 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: team@security.debian.org, 516394@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Tue, 30 Jun 2009 17:30:39 +0000

On Wed, Mar 25, 2009 at 04:52:02PM +0000, 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.

Message #56 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Thijs Kinkhorst <thijs@debian.org>

To: team@security.debian.org, 516394@bugs.debian.org, Gerrit Pape <pape@smarden.org>

Subject: Re: Bug#516394: so what is the solution?

Date: Thu, 2 Jul 2009 20:07:55 +0200

[Message part 1 (text/plain, inline)]

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 (application/pgp-signature, inline)]

Message #61 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: Thijs Kinkhorst <thijs@debian.org>

Cc: team@security.debian.org, 516394@bugs.debian.org, Gerrit Pape <pape@smarden.org>

Subject: Re: Bug#516394: so what is the solution?

Date: Thu, 2 Jul 2009 20:22:04 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Thijs Kinkhorst <thijs@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 - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #66 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: team@security.debian.org, 518169@bugs.debian.org

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Fri, 3 Jul 2009 11:54:46 +0000

On Thu, Jul 02, 2009 at 08:22:04PM +0200, Nico Golde wrote:
> Hi,
> * Thijs Kinkhorst <thijs@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.

Message #71 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Nico Golde <nion@debian.org>

To: team@security.debian.org, 518169@bugs.debian.org

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: so what is the solution?

Date: Fri, 3 Jul 2009 14:05:36 +0200

[Message part 1 (text/plain, inline)]

Hi,
* Gerrit Pape <pape@smarden.org> [2009-07-03 13:53]:
> On Thu, Jul 02, 2009 at 08:22:04PM +0200, Nico Golde wrote:
> > Hi,
> > * Thijs Kinkhorst <thijs@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 - nion@jabber.ccc.de - GPG: 0xA0A0AAAA
For security reasons, all text in this mail is double-rot13 encrypted.

[Message part 2 (application/pgp-signature, inline)]

Message #76 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: 516394@bugs.debian.org

Subject: Re: [security]: Rapid DNS Poisoning in dnscache

Date: Thu, 01 Oct 2009 22:28:35 +0200

Hi

Any reason why there was no upload for this security issue to unstable yet?

Cheers

Luk

Message #81 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Gerrit Pape <pape@smarden.org>

To: Luk Claes <luk@debian.org>, 516394@bugs.debian.org

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 2 Oct 2009 07:27:59 +0000

On Thu, Oct 01, 2009 at 10:28:35PM +0200, Luk Claes wrote:
> Any reason why there was no upload for this security issue to unstable yet?

Hi, I made my position as the maintainer of the package clear in

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36

and some private discussions with the security team.  In my opinion the
issue is fixed sufficiently in unstable and testing, and the same
changes should go into stable.  I offered to prepare the packages, but
the security team declined

 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518169#15

Since then, there's no more information from them I know of.  My
suggestion still stands.

Regards, Gerrit.

Message #86 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: 516394@bugs.debian.org, "Debian Security Team" <team@security.debian.org>

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 02 Oct 2009 19:12:44 +0200

Gerrit Pape wrote:
> On Thu, Oct 01, 2009 at 10:28:35PM +0200, Luk Claes wrote:
>> Any reason why there was no upload for this security issue to unstable yet?
> 
> Hi, I made my position as the maintainer of the package clear in
> 
>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36
> 
> and some private discussions with the security team.  In my opinion the
> issue is fixed sufficiently in unstable and testing, and the same
> changes should go into stable.  I offered to prepare the packages, but
> the security team declined

It seems that the security team does not agree that the bug is
sufficiently fixed or do they (in Cc)?

>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=518169#15
> 
> Since then, there's no more information from them I know of.  My
> suggestion still stands.

Cheers

Luk

Message #91 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Luk Claes <luk@debian.org>

Cc: 516394@bugs.debian.org, "Debian Security Team" <team@security.debian.org>

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 02 Oct 2009 17:26:20 +0000

* Luk Claes:

> Gerrit Pape wrote:
>> On Thu, Oct 01, 2009 at 10:28:35PM +0200, Luk Claes wrote:
>>> Any reason why there was no upload for this security issue to unstable yet?
>> 
>> Hi, I made my position as the maintainer of the package clear in
>> 
>>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36
>> 
>> and some private discussions with the security team.  In my opinion the
>> issue is fixed sufficiently in unstable and testing, and the same
>> changes should go into stable.  I offered to prepare the packages, but
>> the security team declined
>
> It seems that the security team does not agree that the bug is
> sufficiently fixed or do they (in Cc)?

djbdns should not be part of squeeze until it is properly hardened
against cache poisoning.  It is between 100 and 200 times easier than
with other DNS servers.

This hasn't got to do much with bug 516394, though.

Message #96 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Luk Claes <luk@debian.org>

To: Debian Security Team <team@security.debian.org>

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 02 Oct 2009 19:32:17 +0200

Florian Weimer wrote:
> * Luk Claes:
> 
>> Gerrit Pape wrote:
>>> On Thu, Oct 01, 2009 at 10:28:35PM +0200, Luk Claes wrote:
>>>> Any reason why there was no upload for this security issue to unstable yet?
>>> Hi, I made my position as the maintainer of the package clear in
>>>
>>>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36
>>>
>>> and some private discussions with the security team.  In my opinion the
>>> issue is fixed sufficiently in unstable and testing, and the same
>>> changes should go into stable.  I offered to prepare the packages, but
>>> the security team declined
>> It seems that the security team does not agree that the bug is
>> sufficiently fixed or do they (in Cc)?
> 
> djbdns should not be part of squeeze until it is properly hardened
> against cache poisoning.  It is between 100 and 200 times easier than
> with other DNS servers.
> 
> This hasn't got to do much with bug 516394, though.

Ok, removal hint for djbdns added so it gets removed from testing for now.

It would be good if similar cases would also be communicated to the
Release Team and/or filed as RC bugs against the affected packages.

Cheers

Luk

Message #101 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: 516394@bugs.debian.org

Cc: Luk Claes <luk@debian.org>, "Debian Security Team" <team@security.debian.org>

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 02 Oct 2009 19:08:10 +0000

* Florian Weimer:

> * Luk Claes:
>
>> Gerrit Pape wrote:
>>> On Thu, Oct 01, 2009 at 10:28:35PM +0200, Luk Claes wrote:
>>>> Any reason why there was no upload for this security issue to unstable yet?
>>> 
>>> Hi, I made my position as the maintainer of the package clear in
>>> 
>>>  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36
>>> 
>>> and some private discussions with the security team.  In my opinion the
>>> issue is fixed sufficiently in unstable and testing, and the same
>>> changes should go into stable.  I offered to prepare the packages, but
>>> the security team declined
>>
>> It seems that the security team does not agree that the bug is
>> sufficiently fixed or do they (in Cc)?
>
> djbdns should not be part of squeeze until it is properly hardened
> against cache poisoning.  It is between 100 and 200 times easier than
> with other DNS servers.
>
> This hasn't got to do much with bug 516394, though.

Correction: It is relaated to 516394.

Specifically, all publicly available information suggests dnscache
(with the alleged fixes applied) can be poisoned with in 40 minutes or
so on Fast Ethernet, while other implementations withstand an attack
on Gigabit Ethernet for half a day.

The SOA cache bypass is not essential, so patching it away does not
really address the issue.  It is possible to force cache misses by
cycling QTYPEs or QNAMEs, too.

Message #106 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Francis Russell <francis+dbts@unchartedbackwaters.co.uk>

To: Debian Bug Tracking System <516394@bugs.debian.org>

Subject: djbdns: Thoughts on the dnscache cache poisoning issue

Date: Wed, 13 Jan 2010 20:18:25 +0000

Package: djbdns
Severity: normal


Hi there,

please do forgive me if I've got the wrong end of the stick here or the code
I've posted is completely wrong or makes no sense. It would be nice to get
djbdns back into testing. As I understand it, this bug works by getting dnscache
to send extensive numbers of identical DNS requests so that forged responses now
have a chance of being accepted by the majority of in-progress requests.
dnscache does so because it is a) bombarded by these requests b) dnscache's
request dropping policy is used to avoid dnscache ever caching the real
response, so the attack can continue indefinitely.

It seems that the target here is to make dnscache not particularly worse than BIND
or other DNS resolvers under this attack. The request de-duplication patch seems
rather complex and difficult to code-review.

How about this? Under normal requests load, dnscache's behaviour is unchanged.
When dnscache starts dropping requests, dnscache looks for other identical requests,
and if they exist, drops the current request. Hopefully, by the time it is
retried, it can answer it out of the cache as the original request continued
unaffected.

I've put a patch that I think does something like this here:

http://www.unchartedbackwaters.co.uk/files/djbdns-1.diff

(warning: untested, mainly to demonstrate idea)

On the upside, this doesn't have a performance hit when dnscache isn't hitting
its query limit. On the downside, when dnscache does hit its query limit, it'll
cause particular incoming queries to be dropped when they match existing ones in
progress, even if they can be answered out of the cache. Although I believe
in-cache queries should be answered more or less instantly so perhaps this is a
non-issue. Also dnscache will drop queries under load anyway, but this behaviour
might be less desirable. To be honest, I have no idea how often DNS caches under
normal load should experience this problem (hopefully never), nor when
overloaded, how well a DNS cache should perform. Regardless, the patch is much
simpler.

At the very least, I hope this gets this bug to be discussed again.

Regards,

Francis


-- System Information:
Debian Release: squeeze/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 2.6.32.3 (SMP w/2 CPU cores)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

Message #111 received at 516394@bugs.debian.org (full text, mbox, reply):

From: "L. Alberto Giménez" <agimenez@sysvalve.es>

To: 516394@bugs.debian.org

Subject: Is there a plan to get djbdns again into testing

Date: Fri, 19 Feb 2010 21:07:16 +0100

Hi,

I'd love to have djbdns package back in Debian. What's the status of
this bug?

I've read all links from this bug report (and its replies) and it seems
to me that the problem is a DNS protocol problem, not djbdns (it seems
that tere isn't even an exploit).

From the djbdns list you can extract that this "bug" has been present in
all DNS software from the beginning (in fact, DJB disclosed the problem
 publicly circa 1999), so it doesn't seem breaking news at all.

So, the *real* problem here for the security guys is that now djbdns is
*more* vulnerable than other DNS software?

Would they mind to propose a way to have djbdns back in testing? I think
that there is a quite bunch of people using djbdns, and it would be very
nice to have it packaged for Debian.


Thanks a lot.
-- 
L. Alberto Giménez
GnuPG key ID 0x3BAABDE1

Message #116 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Jamieson Becker <jamieson@jamiesonbecker.com>

To: 516394@bugs.debian.org

Subject: Re: Bug#516394: Is there a plan to get djbdns again into testing

Date: Fri, 19 Feb 2010 14:44:39 -0600

+1

On 02/19/2010 02:07 PM, L. Alberto Giménez wrote:
> Hi,
>
> I'd love to have djbdns package back in Debian. What's the status of
> this bug?
>
> I've read all links from this bug report (and its replies) and it seems
> to me that the problem is a DNS protocol problem, not djbdns (it seems
> that tere isn't even an exploit).
>
>  From the djbdns list you can extract that this "bug" has been present in
> all DNS software from the beginning (in fact, DJB disclosed the problem
>   publicly circa 1999), so it doesn't seem breaking news at all.
>
> So, the *real* problem here for the security guys is that now djbdns is
> *more* vulnerable than other DNS software?
>
> Would they mind to propose a way to have djbdns back in testing? I think
> that there is a quite bunch of people using djbdns, and it would be very
> nice to have it packaged for Debian.
>
>
> Thanks a lot.
>    

Message #121 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Matija Nalis <mnalis-debianbug@voyager.hr>

To: 516394@bugs.debian.org

Subject: Re: Bug#516394: Is there a plan to get djbdns again into testing

Date: Sat, 20 Feb 2010 00:39:08 +0100

On Fri, Feb 19, 2010 at 02:44:39PM -0600, Jamieson Becker wrote:
> On 02/19/2010 02:07 PM, L. Alberto Giménez wrote:
>> Would they mind to propose a way to have djbdns back in testing? I think
>> that there is a quite bunch of people using djbdns, and it would be very
>> nice to have it packaged for Debian.

+1

-- 
Opinions above are GNU-copylefted.

Message #126 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Matija Nalis <mnalis-debianbug@voyager.hr>

To: 516394@bugs.debian.org

Cc: control@bugs.debian.org

Subject: so the solution ?

Date: Tue, 12 Oct 2010 00:18:09 +0200

tags 516394 patch
thanks


Hi Gerrit,
I'd appreciate very much if you could spare this update some time. Thanks.

I see in 
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#10

that you have a problem with 
http://www.your.org/dnscache/0001-dnscache-merge-similar-outgoing-queries.patch
due to issues at http://thread.gmane.org/gmane.network.djbdns/13705/focus=13868

Are you aware of new (fixed) version of the patch at:
http://marc.info/?l=djbdns&m=123859517723684&w=1

It should fix mentioned concerns, and it also allows one to "shut down" the
patch at runtime simply by not setting MERGEQUERIES environment variable
(which should probably set by default to keep Security team happy).


Now, I completely agree with you and DJB that the issue at hand is actually
design error in DNS protocol itself, and that being able to poison in few
minutes instead of in few hours is not really such a tremendous difference
that djbdns should be excluded from Debian Stable, and BIND and all other
DNS proxy servers shouldn't (which I wildly guess is the root of your
conflict with security team).

That said, while I agree with DJB that this is fundamental DNS design issue,
I do not see Debian Security Team removing all DNS proxy related packages
(nor would that accomplish anything security-wise), not do I see the DNS
being redesigned from scratch and redeployed all over the world before new 
Debian Stable is out (not even if it took longer than Sarge!) 

While I completely agree with DJB that DNS is fundamentally broken, I just
don't buy into such fatalist and nihilist approach as "it's broken and we're
all doomed".  Now, if there is a ready, deployable right now and
*interoperable right now* fix (which there isn't AFAIK), by all means let's
use it; but until such a beast is available, we should strive to achieve BCP,
even if it just adds "some speed bumps".  Otherwise, the evolution (or at
least the Debian Security Team) will wipe out the weakest (being unpatched
dnscache ATM, after all those years of it being the best).

However, even without knowing about your discussions with security team
(which seem to have gone sour, which make me sad), I might probably agree
with them that solution of lowering MAXUDP to just 20 which you propose in:
in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#36 is not very
good solution (even if not for their reasons!) - while it will happily work 
for SOHO, it would make a package hardly usable on most sites much bigger 
than that.  (I've run dnscache on mid-sized sites to low-end ISP (about
20k users), and more than once did I have to raise the limit from 200 
upwards).

But I can also see why you wouldn't like to "poison" the dnscache code with
mostly untested in the wild patches (especially given whole djbdns/dbndns
distinction).

However, I would very much like to know your stand on that, given the above
(some of it new?) information. As I see, the possible options are (from 
worst to best IMHO):

a) nothing is done -> djbdns/dbndns drops from debian stable completely

b) dnscache is removed from the package; this "fixes" this bug and allows
   at least other parts of the package to enter debian stable (tinydns,
   walldns, rbldns, utils, ...)

c) new patch at http://marc.info/?l=djbdns&m=123859517723684&w=1 is applied,
   with default MERGEQUERIES set in dnscache-run package. I assume that one
   would make security team happy, and since everyone can disable the patch
   if they don't trust it, it might make you happy enough to. You could even
   popup the dialog on upgrade to let the user know or even choose their 
   options.

   Alternatively, Francis patch at
   http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516394#106
   is shown good enough to fix the issue and we use that.


Gerrit, I know you're probably frustrated with this issue, but I'd really
appreciate your take on this.  Is there anything the rest of community can
do?  Do you see any other options?  I guess (a) will happen by default if
nothing is done, and that seems like the worst option for the users of
djbdns to me...

-- 
Opinions above are GNU-copylefted.

Message #133 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Martin Nicholas <reply-2011@mgn.org.uk>

To: 516394@bugs.debian.org

Subject: A Backport please

Date: Thu, 17 Feb 2011 12:08:30 +0000

Could someone _please_ generate a backport (or forwardport!) to lenny?

I'm sure I'm not the only person who has a requirement for tinydns.

The package could even be split into two dnscache and tindyns.

Thanks.

-- 

Regards,

Martin Nicholas.

E-mail: reply-2011@mgn.org.uk

Message #138 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Martin Nicholas <mgn@mgn.org.uk>

To: 516394@bugs.debian.org

Subject: Re: A Backport please

Date: Thu, 17 Feb 2011 12:30:55 +0000

Folks,

I'm so stupid - I meant of course a backport to "Squeeze" (Debian stable).

-- 

Regards,

Martin Nicholas.

E-mail: mgn@mgn.org.uk

Message #143 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Matija Nalis <mnalis-debianbug@voyager.hr>

To: Martin Nicholas <reply-2011@mgn.org.uk>, 516394@bugs.debian.org

Subject: Re: Bug#516394: A Backport please

Date: Sun, 20 Feb 2011 13:11:30 +0100

On Thu, Feb 17, 2011 at 12:08:30PM +0000, Martin Nicholas wrote:
> Could someone _please_ generate a backport (or forwardport!) to squeeze?
> I'm sure I'm not the only person who has a requirement for tinydns.

You can run package from sid or experimental on squeeze:
http://packages.debian.org/search?keywords=dbndns
http://packages.debian.org/search?keywords=djbdns

(without backports, as libraries dependencies did not change yet)

-- 
Opinions above are GNU-copylefted.

Message #148 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Peter Folk <peter@volo.net>

To: 516394@bugs.debian.org

Subject: Re: so the solution?

Date: Wed, 02 Nov 2011 10:23:00 -0500

[Message part 1 (text/plain, inline)]

+1 for Matija's option (c)

[signature.asc (application/pgp-signature, attachment)]

Message #153 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Sergiusz Pawlowicz <sergiusz@pawlowicz.name>

To: 516394@bugs.debian.org

Subject: [CVE-2008-4392]

Date: Mon, 2 Jan 2012 22:40:34 +0000

Dear Security Team,

CVE-2008-4392 has "Candidate" status and is being reviewed for almost
three years now, and still must accepted by the CVE Editorial
Board[0].

Why, after so many years, Debian Security Team, after a clear
statement from prof. Bernstain[1], without confirmation of this rumour
from CVE Editorial Board, still blocks djbdns software from the
society?

Attackers with an access to the network are able to forge DNS
responses, and if we treat is as a bug, we must remove all DNS cache
software from Debian ASAP.

Thanks,
Serge

[0] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-4392
[1] http://cr.yp.to/djbdns/forgery.html

Message #158 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Giuseppe Iuculano <iuculano@debian.org>

To: 516394@bugs.debian.org, Sergiusz Pawlowicz <sergiusz@pawlowicz.name>, Debian Security Team <team@security.debian.org>

Subject: Re: [CVE-2008-4392]

Date: Tue, 03 Jan 2012 10:45:38 +0100

[Message part 1 (text/plain, inline)]

Dear Sergiusz,


it seems my reply to your private email didn't convince you, so replying
again on behalf of the Security Team.


> Dear Security Team,
> 
> CVE-2008-4392 has "Candidate" status and is being reviewed for almost
> three years now, and still must accepted by the CVE Editorial
> Board[0].

This is unimportant, there are a lot of of CVEs under review, this
doesn't mean they are invalid


> 
> Why, after so many years, Debian Security Team, after a clear
> statement from prof. Bernstain[1], without confirmation of this rumour
> from CVE Editorial Board, still blocks djbdns software from the
> society?

Thijs already wrote we are waiting a patch.
All resolver in the Debian archive are properly hardened against cache
poisoning, I really don't understand why djbdns should be an exception.



> Attackers with an access to the network are able to forge DNS
> responses, and if we treat is as a bug, we must remove all DNS cache
> software from Debian ASAP.


If you are privy to a way to poison other resolver in the Debian
archive, please open a bug and we will be happy to discuss the impact.

Cheers,
Giuseppe.

[signature.asc (application/pgp-signature, attachment)]

Message #163 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Sergiusz Pawlowicz <sergiusz@pawlowicz.name>

To: 516394@bugs.debian.org

Subject: [please]

Date: Tue, 3 Jan 2012 13:57:09 +0000

Dear Security Team,
Could you please try to forge my DNS cache, the address is: 127.0.0.1,
or ::1, if you prefer to attack it through IPv6.

Serge

Message #168 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: debian-newmaint@lists.debian.org

Cc: 516394@bugs.debian.org

Subject: Re: djbdns (was: negative vote for maintainer Michael Gilbert)

Date: Fri, 06 Jan 2012 11:46:02 -0800

debian-newmaint really isn't the place for this discussion, so I'll copy
the bug and will send further discussion directly there.  I'm not
subscribed to the bug, so please copy me if you want me to see replies.

Sergiusz Pawlowicz <sergiusz@pawlowicz.name> writes:

> As dnscache in Debian package is not configured to be run out of the
> box, security team effectively prohibits the community from using
> absolutely free, safe and efficient software, as there is no exploits
> available when you configure it on the loopback interface or for hosts
> you trust, e.g. for your cloud of services.

Well, there aren't *no* exploits; there's still the standard DNS cache
poisoning attacks by brute-force port guessing after inducing queries that
are inherent in non-DNSSEC and present in every server, and which can be
done (with more difficulty) even if you can't query the server directly if
you can induce a trusted service to do DNS queries.  But that isn't a
djbdns-specific problem.

The remaining statement on this bug from the security team is:

| djbdns should not be part of squeeze until it is properly hardened
| against cache poisoning.  It is between 100 and 200 times easier than
| with other DNS servers.

I don't understand the basis of that comment just from the bug log.  The
djbdns-specific attack I'm aware of is on SOA, but the bug discussion
indicates that protecting against SOA isn't sufficient and any cache miss
will do.  So apparently there's some hardening other than UDP port
randomization (which djbdns has done for eons) that needs to be done here
from the security team perspective?  It looks like the hardening that they
want to implement is duplicate query merging?

So far as I understand the additional protection provided by duplicate
query merging, the attack that protects against practically requires
direct access to the caching resolver, so listening only on localhost (or
the equivalent) would make dnscache equivalently secure to any other DNS
caching resolver.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #173 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Sergiusz Pawlowicz <sergiusz@pawlowicz.name>

To: 516394@bugs.debian.org

Cc: Russ Allbery <rra@debian.org>

Subject: Re: djbdns (was: negative vote for maintainer Michael Gilbert)

Date: Fri, 6 Jan 2012 20:08:17 +0000

On Fri, Jan 6, 2012 at 19:46, Russ Allbery <rra@debian.org> wrote:

> Sergiusz Pawlowicz <sergiusz@pawlowicz.name> writes:
>
>> As dnscache in Debian package is not configured to be run out of the
>> box, security team effectively prohibits the community from using
>> absolutely free, safe and efficient software, as there is no exploits
>> available when you configure it on the loopback interface or for hosts
>> you trust, e.g. for your cloud of services.
>
> Well, there aren't *no* exploits; there's still the standard DNS cache
> poisoning attacks by brute-force port guessing after inducing queries that
> are inherent in non-DNSSEC and present in every server, and which can be
> done (with more difficulty) even if you can't query the server directly if
> you can induce a trusted service to do DNS queries.  But that isn't a
> djbdns-specific problem.

Dear Russ,
I would like to repeat my statement, this bug, #516394, is not exploitable
if your DNS cache is not directly available for an attacker.

Because of the design of DNS, I do not propose anyone to make any DNS
cache available for any third-parties. But, again, the djbdns Debian package
has no such a service from out of the box, and it must be enabled by an
administrator.

I can prove and admin can configure e.g. httpd to show all your / filesystem
tree, does it mean we must remove httpd from Debian?

Serge

Message #178 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Robert Edmonds <edmonds@debian.org>

To: Russ Allbery <rra@debian.org>, 516394@bugs.debian.org

Subject: Re: Bug#516394: djbdns (was: negative vote for maintainer Michael Gilbert)

Date: Fri, 6 Jan 2012 15:50:00 -0500

[Message part 1 (text/plain, inline)]

Russ Allbery wrote:
> So far as I understand the additional protection provided by duplicate
> query merging, the attack that protects against practically requires
> direct access to the caching resolver, so listening only on localhost (or
> the equivalent) would make dnscache equivalently secure to any other DNS
> caching resolver.

i think this is a rather tenuous assertion.  it's only really true if
the resolver only performs lookups directly approved by the user sitting
at the machine, but on modern systems there are plenty of ways to
remotely induce queries to a caching resolver that only listens on the
loopback interface: HTTP resource loading in web browsers; DNS
prefetching in web browsers; MTAs which generate DNS lookups for HELO,
RCPT, etc.; DNS-based checks in email content filters.

the problem of identical outbound queries was identified well before
CVE-2008-4392; e.g., see VU#457875 from 2002:

    http://www.kb.cert.org/vuls/id/457875

-- 
Robert Edmonds
edmonds@debian.org

[signature.asc (application/pgp-signature, inline)]

Message #183 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Robert Edmonds <edmonds@debian.org>

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: djbdns

Date: Fri, 06 Jan 2012 17:10:09 -0800

Robert Edmonds <edmonds@debian.org> writes:
> Russ Allbery wrote:

>> So far as I understand the additional protection provided by duplicate
>> query merging, the attack that protects against practically requires
>> direct access to the caching resolver, so listening only on localhost
>> (or the equivalent) would make dnscache equivalently secure to any
>> other DNS caching resolver.

> i think this is a rather tenuous assertion.  it's only really true if
> the resolver only performs lookups directly approved by the user sitting
> at the machine, but on modern systems there are plenty of ways to
> remotely induce queries to a caching resolver that only listens on the
> loopback interface: HTTP resource loading in web browsers; DNS
> prefetching in web browsers; MTAs which generate DNS lookups for HELO,
> RCPT, etc.; DNS-based checks in email content filters.

Except that my understanding of the attack is that it requires issuing DNS
lookups for a (*very*) large number of RRs that are not in the local
cache.  This is difficult to force a service to do.  For example, it's
going to be quite hard to do this with HTTP requests in the volume
required, since you have to open a new TCP connection from every address
that you want the web server to look up.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #188 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Florian Weimer <fw@deneb.enyo.de>

To: Russ Allbery <rra@debian.org>

Cc: 516394@bugs.debian.org, debian-newmaint@lists.debian.org

Subject: Re: Bug#516394: djbdns

Date: Sun, 08 Jan 2012 21:18:38 +0100

* Russ Allbery:

> The remaining statement on this bug from the security team is:
>
> | djbdns should not be part of squeeze until it is properly hardened
> | against cache poisoning.  It is between 100 and 200 times easier than
> | with other DNS servers.
>
> I don't understand the basis of that comment just from the bug log.  The
> djbdns-specific attack I'm aware of is on SOA, but the bug discussion
> indicates that protecting against SOA isn't sufficient and any cache miss
> will do.  So apparently there's some hardening other than UDP port
> randomization (which djbdns has done for eons) that needs to be done here
> from the security team perspective?  It looks like the hardening that they
> want to implement is duplicate query merging?

Here's an attempt of a write-up of the maths involved, ready for
pasting into LaTeX.  Hopefully, it's not too embarrassing for me.
It's been a while I did such stuff, probability theory wasn't my
forte, and I have no idea what to do to reduce the final quotient.

Suppose the resolver chooses among $N$ distinct secrets (combinations
of source ports, IP addresses and transaction identifiers, etc.).  To
simplify things, we assume that subsequent choices are uniformly
distributed and independent.

If the resolver merges multiple queries for the same record, all we
can do is to supply $m$ distinct guesses for its choice.  Each
iteration has a probability of $\frac m N$ for success, and we have to
process $m + 2$ packets per total ($m$ guesses, a triggering query,
and its response).  This means that we have to send or receive
\[(m + 2)\left(\frac N m + 1\right) \cong N\] packets on average until
we reach a successful attempt, assuming that $m$ is much smaller than
$N$.

If the resolver does not merge multiple queries, but allows up to $n$
parallel queries, the mist straightforward way is to push up the
success probability by sending $n$ parallel queries per attempt.  For
each of those queries, the resolver chooses a distinct secret.  We can
assume the attacker does the same for her $m$ guesses.  This
experiment results in one of
\[\left(N \atop n\right)\left(N \atop m\right)\]
outcomes.  An outcome is unsuccessful if the victim and attacker set
do not intersect.  This means that their union is one of
$\bigl({N\atop n+m}\bigr)$ sets.  Each of those can be distributed
among victim and attacker in
$\bigl({n+m\atop n}\bigr)=\bigl({n+m\atop m}\bigr)$ ways, resulting
in a total of
\[\left(N\atop n+m\right)\left(n+m\atop n\right)
=\left(N\atop n\right)\left(N-n\atop m\right)\]
unsuccessful outcomes.  Thus, the probablity of failure is
\[\left(N-n\atop m\right)\left/\left(N\atop m\right)\right.
=\left(N-m\atop N-n-m\right)\left/\left(N\atop N-n\right)\right.
.\]
Each of these attempts requires processing of $m + 2n$ packets.

Putting $N = 2^{30}$, $n=200$, $m=10^4$ yields
$2^{30}\cong1.07\times10^9$ packets for the first approach, and
$5.59\times10^6$ for the second approach, which means that the second
approach is approximately $192$ times cheaper.

> Except that my understanding of the attack is that it requires
> issuing DNS lookups for a (*very*) large number of RRs that are not
> in the local cache.  This is difficult to force a service to do.

Your MTA probably does DNS lookups with user-supplied domain names
(for EHLO and perhaps for MAIL FROM:, if you use things like SPF).
Your browser does as well, although there are some attempts at
limiting Javascript-driven parallel requests.

The general problem with these attacks is that they are likely to take
out your local resolver, but that's a different issue.

Message #193 received at 516394@bugs.debian.org (full text, mbox, reply):

From: Russ Allbery <rra@debian.org>

To: Florian Weimer <fw@deneb.enyo.de>

Cc: 516394@bugs.debian.org

Subject: Re: Bug#516394: djbdns

Date: Sun, 08 Jan 2012 20:33:53 -0800

Florian Weimer <fw@deneb.enyo.de> writes:

> Here's an attempt of a write-up of the maths involved, ready for pasting
> into LaTeX.  Hopefully, it's not too embarrassing for me.  It's been a
> while I did such stuff, probability theory wasn't my forte, and I have
> no idea what to do to reduce the final quotient.

Thank you for the analysis!  I understand much better now why the merging
of duplicate queries provides additional hardening against the attack.

> * Russ Allbery:

>> Except that my understanding of the attack is that it requires issuing
>> DNS lookups for a (*very*) large number of RRs that are not in the
>> local cache.  This is difficult to force a service to do.

> Your MTA probably does DNS lookups with user-supplied domain names (for
> EHLO and perhaps for MAIL FROM:, if you use things like SPF).  Your
> browser does as well, although there are some attempts at limiting
> Javascript-driven parallel requests.

Ah, I see.  So you connect to the SMTP server and then stream EHLO
commands at it, and probably open up several parallel connections to the
server and do the same sequence on both to generate the duplicate queries?

> The general problem with these attacks is that they are likely to take
> out your local resolver, but that's a different issue.

I think given the numbers involved proxying the DNS queries through a
service is likely to result in a DoS attack on that service rather than a
successful cache poisoning.  But the impact of a successful cache
poinsoning attack is much worse than that of a DoS, so I can see still
being concerned about it.

-- 
Russ Allbery (rra@debian.org)               <http://www.eyrie.org/~eagle/>

Message #198 received at 516394@bugs.debian.org (full text, mbox, reply):

From: coldtobi <tobi@coldtobi.de>

To: Debian Bug Tracking System <516394@bugs.debian.org>

Subject: Re: [security]: Rapid DNS Poisoning in dnscache

Date: Thu, 13 Feb 2014 20:30:09 +0100

Source: djbdns
Followup-For: Bug #516394

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Hi, 

regarding this bug: It seems that the the German Chaos Computer Clubs' DNS got be owned due to this bug. [1]

It might be argueable if DNS is generally broken or not, but according [2] and the fact that the attack indeed happened sheds a bad light on djbdns -- patches are available since 5 years!

So *please* fix this issue (patches are available!) or remove djbnds from Debian.
Reasons would be RoQA, RC buggy since years, dead upstream, better alternatives available.
i
I'd incline removal, at least of the original version (if the fork is not affected)



- -- 
coldtobi




[1] (Sorry, German) http://www.heise.de/newsticker/meldung/DNS-Server-des-CCC-Anfaellig-wegen-veralteter-Software-2112171.html

[2] http://www.your.org/dnscache/djbdns.pdf


- -- System Information:
Debian Release: jessie/sid
  APT prefers unstable
  APT policy: (500, 'unstable'), (500, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 3.12-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=de_DE.UTF-8, LC_CTYPE=de_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJS/R0xAAoJEJFk+h0XvV02/m0P/16ELF+KNknU2zoABF1CzIAu
GjOXvw888/45EJ7EqKVPhNATVsOVmMmrSFzl/ije8QpEusozBirT8x5IGPgEDrs9
7tjZ9qDUaHobBqqRtq/P/EuRSf01jtWOCVzjUowuQTBLCx2cUn5JV39zz5ZAB/pw
x5BzYnZmZdGeyUlENaYHqj+cowY+2a3E9gPaifSMT1/naZODcxdsVPohFZlfJO9a
ysKzr9dXaXeXOqGJfRPnR1fT+2XqIK5ncGh00cVrAmZBCscQdnl+aUmCYYaZnycX
lQjjNpm0iWCZ0Ugivgr/wa5TI6MiZ95vG5tkoJ19B3A824lmpdF3zTMIVPsvA7Fn
2sE23dCQrQ2U6gR9pRzdm+BqcrBr2+8fn7Bbymc0nPxAgvqJ3oK5ktRTR5MHuQaB
meaceNqhrVIA3PUZcpqXH/aHPhzeQT2ObI++7U4BVZVryQGB7FrM8AfJsmW910hA
wXRbhZPQTAffHeyW87gtvpfmmB5KJntw4/X/MACnbH2AfzJgO+2tmCgGO65xNDC4
FWaz6qp/EJu1Y7+LvRXUXU7LOT2e1Xi7rEF7YNRe/BXtN3TVoEyrkJZzIE6Id7GK
mw1YbCmkcsnwXuZBvfIerAr17o9Lbb/DiyJmxHMtaFhDSAGJz+Zlr2kWZija09jg
ocwHUmeyCQu77e42EfPP
=iphY
-----END PGP SIGNATURE-----

Message #203 received at 516394@bugs.debian.org (full text, mbox, reply):

From: sa9k063 <spam.spam@hfbk-hamburg.de>

To: 516394@bugs.debian.org

Subject: Re: Bug#516394: [security]: Rapid DNS Poisoning in dnscache

Date: Fri, 14 Feb 2014 14:08:05 +0100

Hello,

On 02/13/2014 08:30 PM, coldtobi wrote:
> Source: djbdns
> Followup-For: Bug #516394
> 
> Hi, 
> 
> regarding this bug: It seems that the the German Chaos Computer Clubs' DNS got be owned due to this bug. [1]

no. It is not debians fault when users do not install security updates.

hth

Message #238 received at 516394@bugs.debian.org (full text, mbox, reply):

From: "USPS Parcels Delivery" <clinton.harding@iichgroningen.nl>

To: 516394@bugs.debian.org

Subject: Notification status of your delivery (USPS 7237235)

Date: Mon, 19 Dec 2016 18:31:47 +0000

[Message part 1 (text/plain, inline)]

Dear Customer,

USPS courier was unable to contact you for your parcel delivery.

You can download the shipment label attached!

With anticipation,
Clinton Harding,
USPS Office Agent.

[Item-Delivery-Details-7237235.zip (application/zip, attachment)]

Message #243 received at 516394-done@bugs.debian.org (full text, mbox, reply):

From: Debian FTP Masters <ftpmaster@ftp-master.debian.org>

To: 483096-done@bugs.debian.org,515907-done@bugs.debian.org,516394-done@bugs.debian.org,522420-done@bugs.debian.org,582755-done@bugs.debian.org,603481-done@bugs.debian.org,603482-done@bugs.debian.org,610172-done@bugs.debian.org,611342-done@bugs.debian.org,611503-done@bugs.debian.org,628412-done@bugs.debian.org,636537-done@bugs.debian.org,674562-done@bugs.debian.org,686383-done@bugs.debian.org,688561-done@bugs.debian.org,740357-done@bugs.debian.org,748412-done@bugs.debian.org,756036-done@bugs.debian.org,760543-done@bugs.debian.org,777022-done@bugs.debian.org,788958-done@bugs.debian.org,796118-done@bugs.debian.org,832600-done@bugs.debian.org,

Cc: djbdns@packages.debian.org, djbdns@packages.qa.debian.org

Subject: Bug#870982: Removed package(s) from unstable

Date: Sun, 10 Sep 2017 15:59:23 +0000

Version: 1:1.05-8+rm

Dear submitter,

as the package djbdns has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/870982

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

Send a report that this bug log contains spam.