SAD DNS - Side channel attack

In November 2020 some DNS researchers at Tsinghua University and the University of California, Riverside published a paper on a new way to poison the cache of a DNS resolver.

This Cloudflare blog describes the attack well. It is a relatively complex attack that exploits predictable rate limiting in the operating system to improve the odds of spoofing a connection. The most straightforward remedy is to update the operating system to make ICMP rate limiting unpredictable. The maintainers of the Linux Kernel have already published a patch making the attack less feasible and it is likely that other operating systems affected will do something similar.

This is really an operating system vulnerability, but the effect is to expose DNS resolvers to the possibility of cache poisioning by an attacker spoofing a valid connection. BIND 9 already implements a number of effective mechanisms to defend against spoofing attacks. These include source port randomization and queryID randomization (randomized per port) and connected UDP streams. We implemented RRL (response rate limiting) years ago, which can limit the ability of an attacker to iterate over all the possible ports and queryIDs.

DNS cookies make spoofing attacks much more difficult. BIND will store cookies for any server it has previously communicated with. Servers who have provided BIND with cookies will be protected from spoofing attacks.* Connections from known servers with valid cookies can be exempted from rate limiting or other protective measures, making them more efficient. Once there is a critical mass of support for cookies across the DNS, we can easily implement a ‘stricter’ cookie requirement in BIND that, for example, would require TCP if a valid cookie was not provided. DNS cookies are enabled by default in BIND 9, and according to our research, approximately 17% of TLDs (top level domains) already support cookies. This is a significant minority of servers, but not enough yet to automatically distrust every communication without a valid cookie. Wider deployment of cookies would go a long way to raising the cost of this type of attack.

However, the best overall defense for cache poisoning is to implement DNSSEC. Authoritative operators can establish the authenticitiy of their zone data by signing it, and resolver operators who validate with a strict policy avoid distributing invalid data to users. DNSSEC works to prevent damage due to cache poisioning no matter how it is accomplished, where as the randomizing the ICMP rate limiting fix only prevents this specific vulnerability.

Recommendation for BIND users

In summary, we think this vulnerability is fairly difficult to exploit, but if you are operating a popular open resolver, you should certainly mitigate it. Look for the kernel patch in your chosen operating system or apply the temporary workaround suggested by BlueCat.

We urge more implementers and operators to adopt DNS cookies - they are a lightweight defense and don’t add any additional round trips or communications overhead. In the longer term, this attack is another compelling reason to implement DNSSEC. Those operators who have implemented DNSSEC already can take a minute to congratulate themselves, and perhaps alert their management that they have cleverly avoided this vulnerability.

• while we are proponents of DNS cookies for their lightweight efficiency, we acknowledge they are still vulnerable to reassembly attacks. This problem is addressed by an IETF draft, Defeating DNS/UDP Fragmentation Attacks.

We welcome DNS and security research into possible vulnerabilities in our software or the global DNS system and we encourage coordinated disclosure. To report a suspected security vulnerability responsibly please consult this page or simply email us at security-officer@isc.org.

References

• Web site set up by the researchers to publicize their attack https://www.saddns.net/
• USENIX Paper https://www.usenix.org/conference/usenixsecurity20/presentation/zheng
• Full technical paper https://www.cs.ucr.edu/~zhiyunq/pub/ccs20_dns_poisoning.pdf
• ACM CCS Distinguished Paper Award https://dl.acm.org/doi/10.1145/3372297.3417280
• Cloudflare blog on the attack https://blog.cloudflare.com/sad-dns-explained/
• UC Riverside article on the research https://news.ucr.edu/articles/2020/11/11/dns-cache-poisoning-ready-comeback
• ArsTechnica article on the attack https://arstechnica.com/information-technology/2020/11/researchers-find-way-to-revive-kaminskys-2008-dns-cache-poisoning-attack/
• Tech Republic article on the BlueCat workaround https://www.techrepublic.com/article/how-to-temporarily-mitigate-sad-dns-for-linux-servers-and-desktops/
• NLNET Labs blog on the issue https://blog.nlnetlabs.nl/sad-dns-side-channel-attack-and-unbound/

Nov 15, 2020 CORRECTION:

The initial version of this blog stated that the researchers did not notify ISC before publication. It turns out that they did share a copy of their article with ISC prior to publication, in response to an inquiry about another paper.