Re: dns vulnerabilities

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
Received on Thu Jul 31 2008 - 00:35:01 MDT