Re: update on the djbdns bugs? (fwd)

[email protected] (Paul Jarc)
Newsgroups gmane.network.djbdns
Organization What did you have in mind? A short, blunt, human pyramid?
Message-ID <[email protected]>
Dean Anderson <[email protected]> wrote:
> On Sat, 4 Oct 2008, Dan Kaminsky wrote:
>> Kevin, Dean is claiming that there's some code that prevents
>> simultaneous outstanding queries for the same name, at least to the same
>> host.  Would you mind responding with a trace that shows otherwise?

That claim is actually correct with Jeff's patch.  Dan apparently
doesn't understand what the patch does, so it seems safe to say he
wasn't involved in developing it.

>> The reason you share ports is precisely to make the port random, rather
>> than exhaustable.  There are DNS stacks that won't allow multiple
>> outstanding QID's with the same number, and they're problematic.  The
>> other way to prevent exhaustion is to just not have MAXUDP==65536.
>
> Wrong. If you share ports, then you have to look for a valid query id
> for _ANY_ response on a correct port.  This greatly increases the
> odds of a collision, because then a correct port will have multiple
> possible correct queryids, instead of exactly one.

That's true *if* the attacker already knows which port to use, but
that premise is doubtful.

Dan's point (assuming the attacker doesn't know what port to use) is
that if the resolver ensures that all outgoing queries have distinct
ports, then it's not using the full range of 65536*65536 possible
qid/port combinations.  A totally blind attack is more likely to
succeed against this smaller search space.

I'm not sure he's right, though--with the smaller search space,
knowing that you got a hit with one particular forgery would mean that
you can avoid that port when trying to hit other outgoing queries.
But if you got a hit, you've already won.  (As Kevin said, attackers
typically don't care about consistency, and they inject their poison
via extra, unasked-for (but in-bailiwick) records, not via the record
being asked for.)  OTOH, if you don't know that one particular forgery
got a hit, then that doesn't tell you anything about what ports are in
use.  So I think allowing outgoing queries to sometimes (i.e.,
randomly) use the same port wouldn't really affect the chance of
poisoning.

This point isn't terribly relevant, though--Jeff's patch reduces the
number of outgoing queries, but it doesn't affect how dnscache chooses
ports for outgoing queries.  They remain distinct with or without the
patch.


paul
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.