A number of security sites have announced a DNS protocol problem which was discovered by Dan Kaminsky. For example the advisories for Debian are at:
- DSA-1605 glibc - DNS cache poisoning
- DSA-1604 bind - DNS cache poisoning
- DSA-1603 bind9 - DNS cache poisoning
The attack works if the victim machine uses a predictable source port when it makes DNS queries. Thus the current solution to the problem is to try to randomize the source port of the query.
Now, the default resolving library that is part of glibc and the resolver that comes with BIND 8 do not randomise source ports and are thus subject to attack. This means that until glibc is patched every machine that uses glibc is vulnerable unless one installs a source port randomising DNS caching resolver on each such machine.
Here is what appears to be a simpler alternative:
iptables -t nat -A POSTROUTING -o ! lo -p udp --dport 53 \ -j MASQUERADE --to-ports 1024-65535 --random iptables -t nat -A POSTROUTING -o ! lo -p tcp --dport 53 \ -j MASQUERADE --to-ports 1024-65535 --random
WARNING: The above suggestion may or may not work and may break your machine in all kinds of awful ways!
Will someone more knowledgable than me about the various RFC's confirm whether this would indeed be a "quickfix"?
Ideally, we should expect a suitably patched glibc soon and that would be a better solution
--random switch only works in
Linux kernels with version at least 2.6.22
Update 2: (Thanks to Rick Moen).
--randomswitch only works with Linux kernels with version at least 2.6.24
- There is a good analysis of the vulnerability which points to additional fake records added to fake responses to queries for domains that do not exist.
What this means is that the above quickfix will not work well enough if you run a caching DNS server. You must patch the source for such a caching DNS server.
Secondly, you cannot really use the above quickfix on a machine that provides UDP-based services for remote clients. Those clients may just happen send your service a query from the source port 53 and will get a response from a randomised port in return! For example, you cannot use the above fix on an authority record providing DNS server. Specifically, if you are still running BIND 8 then follow the advice in Simon's comment and upgrade to BIND 9.