CVE-2021-3448: Dnsmasq DNS Cache Poisoning Vulnerability

CVE-2021-3448 Overview

A flaw was found in dnsmasq in versions before 2.85. When configured to use a specific server for a given network interface, dnsmasq uses a fixed port while forwarding queries. An attacker on the network, able to find the outgoing port used by dnsmasq, only needs to guess the random transmission ID to forge a reply and get it accepted by dnsmasq. This flaw makes a DNS Cache Poisoning attack much easier. The highest threat from this vulnerability is to data integrity.

Critical Impact

DNS Cache Poisoning vulnerability allowing attackers to inject malicious DNS responses, potentially redirecting users to attacker-controlled servers or enabling man-in-the-middle attacks.

Affected Products

• Thekelleys dnsmasq (versions before 2.85)
• Red Hat Enterprise Linux 8.0
• Fedora 32, 33, and 34
• Oracle Communications Cloud Native Core Network Function Cloud Native Environment 1.9.0

Discovery Timeline

• 2021-04-08 - CVE-2021-3448 published to NVD
• 2025-12-03 - Last updated in NVD database

Technical Details for CVE-2021-3448

Vulnerability Analysis

This vulnerability affects dnsmasq's DNS forwarding functionality when the software is configured to use a specific upstream DNS server for a particular network interface. Under normal circumstances, DNS implementations randomize both the source port and the transaction ID (TXID) when forwarding queries to upstream servers. This randomization provides entropy that makes DNS cache poisoning attacks computationally expensive.

However, in vulnerable versions of dnsmasq, when interface-specific server configurations are used, the software fails to properly randomize the source port, instead using a fixed port for outgoing DNS queries. This significantly reduces the entropy an attacker needs to overcome when attempting to forge DNS responses.

With the source port predictable or discoverable, an attacker only needs to guess the 16-bit transaction ID (65,536 possible values) rather than both the port and TXID combination. This makes DNS cache poisoning attacks substantially more feasible, as an attacker can flood the dnsmasq server with forged responses until one matches the expected TXID.

Root Cause

The root cause is classified under CWE-358 (Improperly Implemented Security Check for Standard). When dnsmasq is configured with interface-specific server directives, the implementation fails to maintain source port randomization for DNS queries. This design flaw means the DNS implementation does not properly leverage all available entropy sources to protect against response forgery attacks, violating DNS security best practices established since the discovery of the Kaminsky DNS vulnerability in 2008.

Attack Vector

The attack vector is network-based and requires the attacker to be positioned on the same network as the dnsmasq server, or in a position to observe DNS traffic and inject forged responses. The attack proceeds as follows:

1. The attacker identifies a dnsmasq server using interface-specific DNS server configuration
2. The attacker observes or probes to discover the fixed outgoing port used by dnsmasq
3. When a legitimate DNS query is forwarded, the attacker races to send forged DNS responses
4. The attacker sends multiple forged responses with different TXIDs targeting the known source port
5. If a forged response arrives before the legitimate response with a matching TXID, dnsmasq caches the malicious entry

Successful exploitation allows the attacker to redirect DNS queries to attacker-controlled IP addresses, enabling phishing attacks, traffic interception, or denial of service through misdirection.

Detection Methods for CVE-2021-3448

Indicators of Compromise

• Unexpected DNS resolution results pointing to unfamiliar IP addresses
• High volume of DNS traffic from external sources targeting the dnsmasq server port
• DNS cache entries that do not match expected upstream DNS server responses
• Anomalous spikes in DNS query failures or timeouts

Detection Strategies

• Monitor network traffic for unusual patterns of UDP packets targeting the dnsmasq listening port
• Implement DNS response validation by comparing cached entries against known-good DNS servers
• Deploy DNSSEC validation to detect forged DNS responses lacking proper cryptographic signatures
• Review dnsmasq configuration for interface-specific server directives that trigger the vulnerable code path

Monitoring Recommendations

• Enable detailed DNS query logging on dnsmasq servers to track resolution patterns
• Implement network intrusion detection rules to identify DNS cache poisoning attempts
• Monitor for multiple DNS responses for single queries, which may indicate poisoning attempts
• Deploy traffic analysis tools to detect abnormal UDP traffic patterns targeting DNS services

How to Mitigate CVE-2021-3448

Immediate Actions Required

• Upgrade dnsmasq to version 2.85 or later, which includes the fix for this vulnerability
• Review dnsmasq configuration for interface-specific server directives and assess if they are necessary
• Consider implementing DNSSEC validation to provide cryptographic protection against response forgery
• Apply vendor-specific patches from Red Hat, Fedora, or Oracle as appropriate for your distribution

Patch Information

The vulnerability has been patched in dnsmasq version 2.85. Multiple Linux distributions have released security updates addressing this issue:

• Red Hat has published advisories and patches for Enterprise Linux 8.0 (see Red Hat Bug Report)
• Fedora has released updated packages for versions 32, 33, and 34 through their package announcement lists
• Oracle addresses this vulnerability in the Oracle CPU January 2022
• Gentoo has released GLSA 202105-20 covering this vulnerability

Workarounds

• If upgrading is not immediately possible, avoid using interface-specific server configuration directives in dnsmasq
• Implement network segmentation to limit attacker access to the dnsmasq server
• Deploy upstream DNS servers that support and enforce DNSSEC to mitigate the impact of cache poisoning
• Consider using a firewall to restrict which hosts can send DNS queries to the dnsmasq server

# Example: Check dnsmasq version and review configuration
dnsmasq --version
# Look for server= directives with interface specifications that trigger the vulnerability
grep -E "^server=.+@" /etc/dnsmasq.conf
# Update dnsmasq on RHEL/CentOS
sudo yum update dnsmasq
# Update dnsmasq on Fedora
sudo dnf update dnsmasq