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

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?

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?

> 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?

> 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?

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

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.

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

Dempsky.

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