Mast Kalandar

bandar's colander of random jamun aur aam

Thu, 10 Jul 2008

< A flipping trick | · | Balaram on Institutional Archives >

DNS cache poisoning quickfix

dns, floss, lg, security [link] [comments ()] [raw]

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:

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

Update: The --random switch only works in Linux kernels with version at least 2.6.22

Update 2: (Thanks to Rick Moen).

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.


< July 2008 >
   1 2 3 4 5
6 7 8 9101112

2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005, 2004, 2003, 2002, 2001, 2000, 1999, 1997, 1995,