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

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

It sounds like you're saying Jeff's patches modify the randombind()
function to introduce this fallback, but that's not true.  The
fallback is already in unpatched dnscache.

The qmerge patch does reduce the number of ports in use, but that only
makes it more likely that when a new port is chosen, one of the 10
PRNG-chosen ports will be available.  So if there's a difference at
all, a qmerge-patched dnscache has *less* dependency on the kernel's
possibly weaker (or who knows, possibly stronger, depending on the
kernel) port selection.

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

You could do the same thing against an unpatched dnscache, since it
also falls back to a kernel-selected port.

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

But you can't find the right 5 ports in the first place.  Or, more
precisely, qmerge doesn't make it any easier to find them.

If dnscache is under a very low load, then you might find that only 5
ports are in use, and you can attack just those ports.  This is true
with or without qmerge.

If dnscache is under a high load (200 ports in use), you can make a
qmerge-patched dnscache forget about its previous ports and start
using just one new one.  But look at dnscache.c:u_drop() - dnscache
doesn't do anything to tell the kernel to forget about those previous
ports.  As far as the kernel knows, dnscache is still waiting for
responses on those ports.  If the kernel ultimately receives a
response for one of those previous outgoing queries, it will still
deliver that response to dnscache.  Only when dnscache looks through
its udpclient table will it discover that the response is no longer of
interest.  Since the kernel is still keeping track of those previous
ports, they'll still show up in the fuser/port scan.  So the attacker
still has to deal with 200 ports, just as with an unpatched dnscache.

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

I think the DOS attack works just as well on an unpatched dnscache.
If the attacker had to block all 200 queries or legitimate responses,
that would be harder.  But they don't have to do that.  Since they
only need one of their forged responses to be accepted, they get the
same benefit from blocking one query/reponse our of 200 that they get
from blocking one out of one.

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

To the degree that I understand what you've said, I disagree with it.
I'm not ignoring it.

> and to ignore the reputation of the proponents

Close, but not exactly.  I haven't followed their past actions enough
to form any significant opinion of their reputations.  I'm not
interested in their reputations, because even people with bad
reputations can produce good work sometimes (maybe even
unintentionally), and even people with good reputations can produce
bad work sometimes.  So I'm trying to judge this piece of work on its
own.

And if the worst action that established a bad reputation for any of
these people is making a grab for attention, while also getting a
long-standing problem fixed, well... I really can't get too worked up
over that.

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

This statement seems to contain the idea that we are up to the task of
independently verifying a problem reported by someone untrustworthy,
but we are not up to the task of independently evaluating their
suggested solution - they are bound to sneak something past us.  I
disagree with that idea.

> Side effects which are made more obvious by the absence of these
> side effects in my design.

Your design might have different side effects.  Off the top of my
head, I wonder if you'll have trouble running into MAXTCP more
frequently, since that's only a tenth as large as MAXUDP.  But there's
no use speculating about the potential flaws of an as-yet-unwritten
patch, so I haven't thought much about it yet.


paul