On mån, 2008-07-28 at 09:22 -0400, Jeremy Hall wrote: > I am writing to you and not a squid list because i don't know if the > vulnerability most recently discovered in most DNS implementations is > publically known. Does squid's internal DNS suffer from this > vulnerability, or does it simply rely on DNS on the machine?
There is certainly room for improvement. But it's not specific to this new attack. Squid is a fairly typical caching DNS client. Not a DNS cache. The ipcache (and fqdncache) in Squid is more like a nscd OS component, not a DNS cache in itself. Squid mostly relies on the resolver specified in resolv.conf or squid.conf. It do not perform recursion on it's own. Squid only caches the exact query, not glue or additional RRs. Such caching is dutifylly left to the resolver used. Instead Squid accepts any A (or AAAA) records returned in the answer section as authorative for the query. Squid uses a random QID, but the randomization can be significantly improved. Standard psuedo random()%65536 generator, seeded with the startup time. But good resolvers replaces the QID when forwarding the query so this is less of a problem as the attacker can not easily deduce the RNG used by Squid (only the resolvers RNG). Squid do verify that the query section of the response matches the query sent. Squid does use a single OS allocated port number for the DNS client, static for the lifetime of the Squid proces. The randomness of this static port assignment is OS dependent. But this port number is only visible between Squid and the DNS resolver. By default responses is only accepted if coming from the IP of the queried DNS server. This restriction can be relaxed in squid.conf however. And in many setups both the IP of Squid and the resolver is easily identified. So I think the rating for these issues in Squid is fairly low. The attack vector is really the DNS resolver used by Squid. But yes, a very patient attacker may be able to discover the source port used by Squid and eventually manage to win the race even without deducing the QID RNG, but with responses cached per the DNS TTL is't a very slow attack. But sites using a very short TTL and slow DNS servers is at higher risk for this to succeed. I think the best long term "fix" to this whole family of problems is probably to by default use TCP to the DNS resolvers instead of UDP. The overhead in latency is about the same (assuming that the TCP connection is already established), and less overhead for Squid compared to assigning unique UDP ports to each DNS query.. but will have some added complexity in dealing with stalled DNS connections (firewall session timeout etc...) Regards Henrik
