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

On Tue, 24 Feb 2009, Paul Jarc wrote:

> Dean Anderson <[email protected]> wrote:
> > On Wed, 18 Feb 2009, Paul Jarc wrote:
> >> I don't think this attack works any better against a qmerge-patched
> >> dnscache.  Although dnscache forgets about its previous outgoing
> >> queries, the kernel doesn't know that it has forgotten.  There's no
> >> external evidence that would show up in the attacker's probe.
> >
> > Your analysis is incorrect:
> >
> > 1. The state of the kernel is indeed affected by the rate of ports being
> > consumed and returned. (previously explained)
> 
> If by "the state of the kernel" you mean the kernel's entropy pool,
> then we agree, but I don't see how that relates to what I said above.
> If you mean that the kernel will handle an incoming response
> differently based on whether dnscache has forgotten the outgoing
> query, then that would be relevant, but I disagree.  I don't think
> you've given any explanation of how that could be.
>
> > The fewer ports (a single port) might be easier to discover and
> > identify.  (previously explained)
> 
> You haven't explained how to distinguish recently-forgotten ports from
> still-waiting-for-response ports.  With the attack I described, making
> that distinction is necessary if you want to reduce the number of
> ports to consider.

Don't need to; such a distinction (recently forgotton??? WTF?) is
nonsense.

The state of the kernel is represented by the ports in use, the 
processes owning those ports, and the next port that the kernel will 
allocate.

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.

The first and most obvious is to consume a lot of ports on the target,
making it more likely that DNScache will use the next kernel assigned
port, and having some idea of what that port number will be. The
probability and difficulty of this attack is hard to compute, but I am
working on it.

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. I believe the case of a fast port scan is equivalent.  
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. That would be 200 times harder than one port, not 200 times
easier, as Demsky wrongly asserted. Picking a single port out of 200
isn't easier because one doesn't know if that port was part of same
Query or is being used by another Query; there is a probability of
guessing wrong.  But if one can be certain that exactly one port is used
for a Query, then instead of 200 ports in used by DNScache, there are
only for example 5 (1 for the target Query plus regular load), then a
brute force attack on all 5 is much easier.  Chances for success is
improved further by the fact that there is only one real query packet
and only one real query response. Those 2 legitimate packets can be
attacked via regular DOS methods, lengthening the time for the brute
force attack to succeed. Ensuring a exactly one port per Query and
exactly one query/response pair is a very bad side effect.


> Regardless, there's no reason not to fix the problem, if the solution
> doesn't introduce new problems.

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.

> So far, I haven't seen any reason not to apply the qmerge patch.

I have seen several reasons, and I've explained them. I think you've
chosen to ignore both the technical analysis and to ignore the
reputation of the proponents, and to ignore basic good practice in
dealing with changes proposed by blackhats. The practice is to take
exploits and fix them without further input from the blackhats. Instead,
you've programmed the design of the blackhats, despite knowledge of the
side effects in their design. Side effects which are made more obvious
by the absence of these side effects in my design.

		--Dean


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