Vulnerability Note: VU#434904: Dnsmasq is vulnerable to memory corruption and cache poisoning
Dnsmasq is vulnerable to a set of memory corruption issues handling DNSSEC data and a second set of issues validating DNS responses. These vulnerabilities could allow an attacker to corrupt memory on a vulnerable system and perform cache poisoning attacks against a vulnerable environment.
Dnsmasq is widely used open-source software that provides DNS forwarding and caching (and also a DHCP server). Dnsmasq is common in Internet-of-Things (IoT) and other embedded devices.
JSOF reported multiple memory corruption vulnerabilities in dnsmasq due to boundary checking errors in DNSSEC handling code.
- CVE-2020-25681: A heap-based buffer overflow in dnsmasq in the way it sorts RRSets before validating them with DNSSEC data in an unsolicited DNS response
- CVE-2020-25682: A buffer overflow vulnerability in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data
- CVE-2020-25683: A heap-based buffer overflow in get_rdata subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
- CVE-2020-25687: A heap-based buffer overflow in sort_rrset subroutine of dnsmasq, when DNSSEC is enabled and before it validates the received DNS entries
JSOF also reported vulnerabilities in DNS response validation that can result in DNS cache poisoning.
- CVE-2020-25684: Dnsmasq does not validate the combination of address/port and the query-id fields of DNS request when accepting DNS responses
- CVE-2020-25685: Dnsmasq uses a weak hashing algorithm (CRC32) when compiled without DNSSEC to validate DNS responses
- CVE-2020-25686: Dnsmasq does not check for an existing pending request for the same name and forwards a new request thus allowing an attacker to perform a “Birthday Attack” scenario to forge replies and potentially poison the DNS cache
Note: These cache poisoning scenarios and defenses are discussed in IETF RFC5452.
The memory corruption vulnerabilities can be triggered by a remote attacker using crafted DNS responses that can lead to denial of service, information exposure, and potentially remote code execution. The DNS response validation vulnerabilities allow an attacker to use unsolicited DNS responses to poison the DNS cache and redirect users to arbitrary sites.
These vulnerabilities are addressed in dnsmasq 2.83. Users of IoT and embedded devices that use dnsmasq should contact their vendors.
Follow security best-practices
Consider the following security best-practices to protect DNS infrastructure:
- Protect your DNS clients using stateful-inspection firewall that provide DNS security (e.g.,
stateful firewalls and NAT devices can block unsolicited DNS responses, DNS application layer inspection can prevent forwarding of anomalous DNS packets).
- Provide secure DNS recursion service with features such as DNSSEC validation and the interim 0x20-bit encoding as part of enterprise DNS services where applicable.
- Prevent exposure of IoT devices and lightweight devices directly over the Internet to minimize abuse of DNS.
- Implement a Secure By Default configuration suitable for your operating environment (e.g., disable caching on embedded IoT devices when an upstream caching resolver is available).
Moshe Kol and Shlomi Oberman of JSOF researched and reported these vulnerabilities. Simon Kelley (author of dnsmasq) worked closely with collaborative vendors (Cisco, Google, Pi-Hole, Redhat) to develop patches to address these security vulnerabilities. GitHub also supported these collaboration efforts providing support to use their GitHub Security Advisory platform for collaboration.
This document was written by Vijay Sarvepalli.