Re: 2 forwarded messages...DNSEXT discussion of Day and Kaminsky

On Wed, 18 Feb 2009, Paul Jarc wrote:

> Dean Anderson <[email protected]> wrote:
> > - If one agrees that reducing the number of ports consumed might affect
> > the entropy of the port number
> 
> You keep saying this, but you never explain it.  I'm trying to figure
> out what you mean, but I haven't had any success so far.  Analogies
> with popcorn poppers aren't very illuminating.  Please provide
> complete, technical detail.

I believe you haven't paid attention to my previous emails. There is 
nothing here that hasn't been already posted.  

The port selection is not fully random: 
=======================================

In dns_transmit.c you will find a function called randombind:

static int randombind(struct dns_transmit *d)
{
  int j;

  for (j = 0;j < 10;++j)
    if (socket_bind4(d->s1 - 1,d->localip,1025 + dns_random(64510)) == 
0)
      return 0;
  if (socket_bind4(d->s1 - 1,d->localip,0) == 0)
    return 0;
  return -1;
}

This function tries 10 times to get a random port, and then gives up. It
might fail because the port selected by the PRNG is in use. The port
number is not really random; The port number can be constrained by
external factors.

Why might this be important?  
============================

If one has fewer ports being used by DNScache, one might be able to
discover those ports by scanning.  Blocking ICMP might help, but an
unprivileged process on the same machine can't be blocked, and can
usually get a list of ports. In either case, instead of trying to find
200 ports out of 64510, one knows the 200 ports + plus those in use by
other things. In that case, the task is significantly reduced. If there
is just one port for DJBDNS plus those in use by other things, the task
is easier still.  Reducing the number of ports being used and returned
affects the entropy of the port numbers and makes another attack
possible.




> The change suggested by Kevin Day, and implemented by Jeff King, and
> having nothing whatsoever to do with Dan Kaminsky as far as I can
> tell,

Day and Kaminsky have been working together since Kaminsky claimed that
DNScache was vulnerable at Blackhat last summer.  Maybe you forgot about
this message from Day:

=============================================================== 
Date: Thu, 7 Aug 2008 13:48:55 -0500 
From: Kevin Day <[email protected]>
To: [email protected] 
Subject: Re: Kaminsky on djbdns bugs

An announcement will be made as soon as possible about the scope and
details of what Dan Kaminsky is referring to. I'm trying to work with
djb and confirm everything with him this before making it public.

Patience guys, and relax - this isn't serious.

-- Kevin
===============================================================

Remember this claim by Kaminsky:

 * DJB WAS RIGHT
   -- NOT PERFECT -- he has bugs too, as
      we're seeing (and patching, don't ask)
       * For example, he didn't implement
         birthday attack protection - he
         believed port randomization was
         enough
       * DJBDNS has other known issues too

I exchanged email with both Kaminsky and Day offlist about their
proposed changes all fall. The first set of changes they proposed
included a combination of two birthday attacks, making a new, trivial
attack. They also had the birthday attack math incorrect. The rest of
their story about discoveries didn't hold up, either.

> does not reuse the same port for multiple outgoing queries.  It only
> causes fewer outgoing queries to be sent while dnscache is under a
> birthday attack.  When it isn't under such an attack, the behavior is
> unchanged.  And in any case, when outgoing queries are sent, the port
> numbers are chosen the same way as before.  What's the problem?

See above.  Kaminsky/Day/King's proposal alters the entropy of the port
numbers. That's a problem, or at least a potential problem.  I agree its
hard to analyze, but given the reputation of the proponents, I think
there are other alternatives that are better.  And my proposal __IS__
better because TCP is invulnerable to poisoning except by MITM.

		--Dean


-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000