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