The latest DNS related debacle is (as per usual) related to cache poisoning, which is where your adversary manages to convince your resolver (or more specifically, one of the caches between your resolver and the site/service you are intending to connect to) that they are in fact the one you want to be talking to. Note that these are not man-in-the-middle (MitM) attacks; if someone can see your DNS queries you're already toast - these are effective, remote attacks that can be devastating:
Consider for example your average company using POP3 to retrieve mail from their mail server every few minutes, in conjunction with single sign on; convince their cache that you are their mail server and you will have everyone's universal cleartext password in under 5 minutes.The root of the problem(s) is that the main security offered in a DNS transaction is the query ID (QID) for which there are only 16 bits (eg 65,536 combinations). Even when properly randomised (as was already the case for sensible implementations like djbdns, but not for earlier attempts which foolishly used sequential numbering), fast computers and links can make a meal of this in no time (read, seconds), given enough queries. Fortunately you typically only get one shot for a given name (for any given TTL period - usually 86,400 seconds; 1 day), and even then you have to beat the authorative nameserver with the (correct) answer. Unfortunately, if you can convince your victim to resolve a bunch of different domains (a.example.com, b.example.com ... aa.example.com and so on) then you'll eventually (read, seconds) manage to slip one in.
So what you say? You've managed to convince a caching server that azgsewd.victim.com points at your IP - big deal. But what happens if you slipped in extra resource records (RRs) for, say, www.victim.com or mail.victim.com? A long time ago you might have been able to get away with this attack simply by smuggling unsolicited answers for victim.com queries along with legitimate answers to legitimate queries, but we've been discarding unsolicited answers (at least those that were not 'in-baliwick'; eg from the same domain) for ages. However here you've got a seemingly legitimate answer to a seemingly legitimate question and extra RRs from the same 'in-baliwick' domain, which can be accepted by the cache as legitimate and served up to all the clients of that cache for the duration specified by the attacker.
This is a great example of multiple seemingly benign vulnerabilities being [ab]used together such that the result is greater than the sum of its parts, and is exactly why you should be very, very sure about discounting vulnerabilities (for example, a local privilege escalation vulnerability on a machine with only trusted users can be turned into a nightmare if coupled with a buffer overrun in an unprivileged daemon).Those who still think they're safe because an attacker needs to be able to trigger queries are sadly mistaken too. Are your caching DNS servers secure (bearing in mind UDP queries can be trivially forged)? Are your users machines properly secured? What about the users themselves? Will they open an email offering free holidays (containing images which trigger resolutions) or follow a URL on a flyer handed to them at the local metro station, café or indeed, right outside your front door? What about your servers - is there any mechanism to generate emails automatically? Do you have a wireless network? VPN clients?
Ok so if you're still reading you've either patched already or you were secure beforehand, as we were at Australian Online Solutions given our DNS hosting platform doesn't cache; we separate authorative from caching nameservers, and our caches have used random source ports from the outset. This increases the namespace from 16 bits (65k combinations) to (just shy of, since some ports are out of bounds) 32 bits (4+ billion combinations). If you're not secure, or indeed not sure if you are, then contact us to see how we can help you.