On 2013-09-05, at 4:25 PM, Florian Weimer <[email protected]> wrote:
> Exploiting this vulnerability successfully over the Internet against > resolvers processing real-world traffic still seems difficult to me, > at least if the resolver uses the Linux TCP/IP stack. This is not > completely idle speculation because some of us tried to implement this > attack several times over the past few years, putting in quite a bit > of effort and failed. Compare this to the TTL evasion vulnerability, > for which attacks were really easy to implement. Florian, do you mind elaborating on what part of the attack is most difficult? In Linux, I believe the accidental mitigation for this is the ipfrag_max_dist setting (newer version of the paper discusses this), which is only 64 fragments per source. So this gives the attacker a 1/1024 chance each attempt to guess the correct IP ID. That part doesn't seem to meet the criteria of difficult (just keep repeating the attack with different IP ID and updated checksum). The difficult part to me is soliciting just the right referral response which is 1) large enough to be fragmented and 2) organized in such a way that the glue records which the attacker replaces are cached according to the victim resolver's caching policies. The attacker of course is constrained by the contents of the first fragment, i.e., the authority and answer counts in the DNS header. He is also constrained by the situations in which e.g. BIND will accept a glue record (for example I have read they are ignored if SOA RR present, but I don't know all the details). > (But keep in mind that other stacks have different beahviors and > defaults, and could well be much more vulnerable.) Not just stacks, but different resolver software. Again, even though Linux places a fairly restrictive limit on the number of fragments that can be pre-loaded, this is still just a 16-bit range to brute force. > Deploying IPv6 also happens to help, due to the increased fragment ID > size. Like reflective denial-of-service attacks, this potential > attack could be greatly mitigated by source IP address validation at > the ISP level. This decade, right? Here is a thought, but I will defer to the protocol experts on plausibility. The resolver knows the size of each DNS message it parses. What if it didn't trust glue records contained within large (i.e., > 1400 bytes or so) responses? In these cases, the resolver sends a separate query to resolve the dangling authority NS records. This introduces overhead, but only for large replies. It also makes a few assumptions, namely that the fragmentation point is something around 1500 bytes (and not something lower), and that the attack is only practical against the glue records, not the authority section. May be able to play games with name compression there though… perhaps it is as least worth discussing as an additional barrier. For PoC, contact Shulman herself? The slide deck describing the attack has Wireshark screenshots suggesting that the attack has already seen real-world testing. -Aaron _______________________________________________ dns-operations mailing list [email protected] https://lists.dns-oarc.net/mailman/listinfo/dns-operations dns-jobs mailing list https://lists.dns-oarc.net/mailman/listinfo/dns-jobs
