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

On Wed, 11 Feb 2009, Jeff King wrote:

> On Wed, Feb 11, 2009 at 04:09:54PM -0500, Dean Anderson wrote:
> 
> > These two explain the combined birthday attack pretty decently, I think.
> > 
> > I'm going to be looking at Jeff King's patches to see if they
> > implement the combined birthday attack. The 'merge similar outgoing
> > queries' sounds on the surface a lot like the plan to 'reuse
> > queryids' that does suffer from the combined birthday attack.
> 
> OK, I see now why you think this would make things worse, but it
> doesn't. The merge-outgoing patch does not reuse ports or reuse
> queryids for a new packet (which would, as you say, make it easier for
> an attacker to succeed).  They actually avoid sending another packet
> entirely if we have a query that would have a coincident name (and
> instead wait for the other packet to show up, and use the answer for
> both).

Actually, one of the first problems I see is that your patch discards
repeated queries from multiple hosts that ask the same question.  You
don't queue the questions; the same question could from different hosts,
and you only answer the first question to the first host. This is just a
bug that can be fixed by queuing all the questions, and then answering 
all of them when you get a response.

Still looking....

What I'm also concerned about, is that your change may fix a problem
that an attacker may have. Day describes the oldest queries being
dropped. The effect this has is to restart the birthday attack before
the required packets have been received, or rather reduce the number of
urns, mid-attack. That makes it harder for the single birthday attack to
succeed. Reducing the number of ports in MAXUDP increases the number of
packets necessary to spoof dnscache.  If queries come in, and knock out
attacker's queries, this is the same (very nearly) as reducing the size
of MAXUDP. Kind of like accidentally hitting the reset button...

I'm also trying to figure out if seeming to reducing MAXUDP to one via
caching improves another attack, perhaps by holding a single query in
reception for longer, preventing it from being bumped...preventing the
reset button from going off.  This might be very useful if the UDP port
number is predicable.  It might make it easier to write the exploit:  
Just keep sending the same query, send lots of responses. As it is now,
the ports and QID's would keep changing, so the exploit has to wait for
a while before sending a packet. How long to wait depends on the server
load. Not having to worry about the wait time may make it way easier for
the attacker, especially if the UDP port might be predictable.





At 200 MAXUDP, it takes 28 million packets to spoof dnscache. You'd
notice that, so changing DNScache doesn't appear to be necessary.

So far, I haven't seen anything in any of these changes that makes
DNScache stronger, nor anything that fixes a weakness. 

Making TCP queries is by far the strongest security within the protocol,
and any UDP change will never come close to TCP security:  32 bit random
sequence number + 16 bit QID = 48 random bits.  DNSSEC is a lot slower
than TCP, and creates new DDOS attack vectors.

I'll keep you posted, in the meantime, I still advise people not to run
these patches until they are thoroughly vetted.  DNScache isn't
vulnerable now to any practical attack, and one wonders why take a risk.


		--Dean


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