https://issues.apache.org/SpamAssassin/show_bug.cgi?id=6221
--- Comment #12 from Simon Arlott <[email protected]> 2010-01-27 12:45:47 UTC --- (In reply to comment #11) > (in reply to comment 10) > > You are correct that the fix to Dan Kaminsky's security problem involved > making > the port unpredictable, but wouldn't that imply using a port number selected > randomly from the entire space of available ports within the 16 bit space? A > single server can't keep reusing the same one or few port numbers because then > an attacker can spend a little time looking at which ones are being used and > it > would be predictable. So I would think that maybe we get what we need from the > security fix. I haven't had time to test this out, but when we were working on The fix is an unrelated issue and concerns the communication between your local caching nameserver and remote servers. The only similarities are the need to use the full range of ports and IDs (previous DNS servers only ever using one source port being most vulnerable to this). > this, before the big DNS security fix, I found that when the OS chose the port > it wold just start with the first number in the available range, then > increment > the port number with each new port, and do that with each process. It woud be > interesting to see what the pattern looks like now. It still does this on Linux (but the new port is global not per process). > I don't see how we can make a timeout work. here is what happens: A query is > sent out on port A with 16-bit ID B. No response is received within the > lifetime of the listener and the listener times out. Possibly another process > sends out a query that also is on port A with ID B. Then the reply from the > first query finally arrives from the remote nameserver, arriving on port A > with > ID B, and that reply is incorrectly processed by the listener that is waiting > for the reply to the second query. > > Where can we or the sysadmin put a timeout that would help in that scenario? Remote nameservers should not be used because SA does not cache replies. A local caching nameserver is required to be efficient (or you keep externally querying the same records over an over again every time the same IP/domain sends you email). Two processes cannot share the same port, and you control both SA and the local nameserver. As long as the local nameserver discards the query from SA when it knows SA will time out waiting for a response, there is no problem with replies going to the wrong process. Nameservers typically have much longer timeouts that their clients (which the RFC allows for, as clients are supposed to simply retry [another server]). > The purpose of randomising the port is so that the probability of the almost > 32-bit combination of port and ID colliding is too low to worry about. If too > few port numbers are used the probability of collision on just the 16 bit ID > is > too high for the number of DNS queries that are generated in a high volume > situation. The full range of local source ports is available. There is no reason why iterating through them should be any worse than the (not guaranteed) random selection. The implication that a small port range will cause SA major issues means that the configuration option would need to be "OS allocated" or "random" and not allow a range. In either case, it should be possible to stop SA trying to bind arbitrary ports that it chooses as it does not necessarily have free reign over the system. -- Configure bugmail: https://issues.apache.org/SpamAssassin/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug.
