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

On Fri, 27 Feb 2009, Matthew Dempsky wrote:

> On Wed, Feb 25, 2009 at 12:08 PM, Dean Anderson <[email protected]> wrote:
> > The randombind() function tries 10 times to allocate a port, and if that
> > fails, the port given by the kernel is used. So the port bound by
> > randombind() is not a strong random number.  This is a side-effect of
> > the Kaminksy/Day/King patch, and it is desirable to have a patch that
> > has few or no side effects. There are several ways that I can think of
> > to exploit the weakness in this number.
> 
> Do you agree that dnscache with the qmerge patch uses the same number
> of or fewer UDP ports at a time than stock dnscache?

Fewer. So 'yes'

> If yes, then can you explain how you think dnscache using fewer UDP
> ports at a time causes randombind() to have to fallback to the
> operating system more frequently?

I can. But you have causes and effects mixed up.  On the usage of UDP
ports: DNScache isn't the only consumer of ports on a system.  Anything
can consume UDP ports.  By having DNScache use fewer ports, any
non-random behavior of randombind has a greater impact on the fewer
ports used by DNScache.  DNScache becomes more predictable for a longer.  
Attackers can exploit that non-randomness to their benefit.

> > The first and most obvious is to consume a lot of ports on the target,
> 
> Do you agree that such an attack is equally valid against both stock
> dnscache and dnscache with the qmerge patch?

Valid? Attack cannot be valid or invalid. The question is about the
chances of success of a given type of attack.  The chances of success
are not equal. Qmerge makes other attacks more successful while making
one attack more difficult.  By contrast, I propose to make the one
attack harder by trying to detect it and falling back to TCP without
tinkering with anything that will make the other attacks easier.

> > The second way is to have an unprivileged account on a multiuser
> > machine that runs a cache, and just ask (via fuser) for which ports
> > belong to which processes.
> 
> Do you agree that such an attack is equally valid against both stock
> dnscache and dnscache with the qmerge patch?

Same answer.


> > In this case, during the birthday attack one finds out the 200 ports
> > that belong to DNScache, but one must still conduct a brute force
> > attack on all 200.
> 
> No, you're wrong.  An attacker only has to successfully forge one
> response, not 200.

An attacker must send the right QID to the right port. They do not know
which of the 200 ports have which QID, NOR do they know which of the 200
ports are using THEIR Query tuple. So they have to send all QIDs to all
200 ports.  So your assumption that they could pick one is wrong.

> If your dnscache has 200 active queries to a.ns.yp.to and b.ns.yp.to
> asking for the A records for cr.yp.to, I only have to successfully
> forge a response to one of those queries to give you poisonous MX
> records for cr.yp.to that you'll save.  The other 199 queries can be
> answered legitimately and your cache is still poisoned.

No, if any of the other 199 are responded before the attack is
successful, then the query is answered and the attack fails. Time is not
on the side of the attacker, nor will it be easy for the attacker to DOS
attack all of the other 199 query/response pairs.  By contrast, under
the Qmerge patch, the attacker _knows_ there is only one query/response
pair, and they can conduct a DOS attack on either of those two packets,
lengthening the time for their attack to succeed. Qmerge helps the
attacker.

> > That would be 200 times harder than one port, not 200 times easier,
> > as Demsky wrongly asserted.
> 
> Dempsky.

Got it. Sorry for the mispelling.

> > I agree. That's why I came up with a way to detect the birthday attack
> > and compensate by an invulnerable TCP fallback without doing any
> > tinkering that might introduce new problems.
> 
> Not all servers provide TCP fallback.  E.g., yp.to's name servers only
> provide DNS over UDP.

That's a good point. I guess fallback fails in that case.  But DNScache
falls back to TCP in other circumstances, as do other nameservers, so I
think such failure is already unavoidable if TCP is not supported.

Supposing one has detected a birthday attack, and TCP fallback fails,
would one want the possibly poisoned record, or no record?

		--Dean


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