CVE detail
CVE-2013-0198
Dnsmasq TCP DNS Query Amplification via Prohibited Interfaces
Search another CVE
Summary
CVE-2013-0198 is a medium-severity flaw in dnsmasq before 2.66test2 that allows remote attackers to trigger traffic amplification by sending spoofed TCP-based DNS queries from interfaces that should be prohibited. This incomplete fix for CVE-2012-3411 can lead to denial of service in certain libvirt configurations.
Why exploitable
Why Exploitable?
For CVE-2013-0198, no EPSS data is available, meaning the empirical probability of exploitation in the wild is not quantified. The absence of CISA KEV and public exploit references suggests that there is currently no widespread exploitation known. However, the vulnerability remains relevant as it is an incomplete fix for CVE-2012-3411 and can lead to denial of service in certain libvirt configurations. Organizations should verify their dnsmasq version and update to 2.66test2 or later. Additionally, they should validate network configurations, especially interface restrictions, to ensure only authorized interfaces can process DNS queries. Although the immediate threat appears low, remediating the known vulnerability is advisable to close potential attack vectors.
Technical details
Overview
CVE-2013-0198 is a medium-severity vulnerability (CVSS base score 5.0) affecting dnsmasq versions prior to 2.66test2. The flaw exists when dnsmasq is used with certain libvirt configurations, allowing it to reply to DNS queries originating from interfaces that are supposed to be prohibited. This behavior enables remote attackers to cause a denial of service through traffic amplification using spoofed TCP-based DNS queries. The vulnerability is a direct result of an incomplete fix for CVE-2012-3411, which addressed a similar issue with UDP queries. The issue was publicly disclosed in early 2013 and affects Linux distributions including Debian, Ubuntu, and Gentoo. Security teams managing virtualized environments that rely on dnsmasq for DNS forwarding should prioritize patching to prevent potential network disruption.
Technical details
The root cause of CVE-2013-0198 is improper input validation (CWE-20) in dnsmasq's handling of DNS queries received over TCP. Specifically, dnsmasq fails to enforce interface restrictions when processing TCP-based DNS queries, allowing queries from interfaces that should be blocked by configuration. This is an incomplete fix for CVE-2012-3411, which addressed the same issue for UDP queries but left TCP queries vulnerable. The vulnerable component is the DNS forwarder in dnsmasq, and the affected versions are all releases before 2.66test2. Attack prerequisites include network access to a dnsmasq instance configured with interface restrictions (e.g., via libvirt). The trust boundary is the network interface layer; dnsmasq should only respond to queries from allowed interfaces, but this flaw bypasses that control. The weakness is classified as CWE-20, indicating a failure to properly validate input (in this case, the source interface of TCP DNS queries).
Impact
The primary impact of CVE-2013-0198 is a denial of service (DoS) condition achieved through traffic amplification. An attacker can send spoofed TCP-based DNS queries to a vulnerable dnsmasq server, causing it to generate responses that are larger than the queries, thereby amplifying network traffic. This can saturate the network link or exhaust server resources, leading to service disruption for legitimate users. The confidentiality and integrity of data are not directly compromised, but the availability of DNS services is at risk. In virtualized environments, this could disrupt name resolution for multiple virtual machines, affecting business operations. Downstream abuse scenarios include using the vulnerable dnsmasq as a reflector in DDoS attacks, amplifying attack traffic against third-party targets. Defenders should assess the exposure of their dnsmasq instances and consider the potential for network-level DoS.
Exploitation steps
- Identify a vulnerable dnsmasq instance (version < 2.66test2) that is configured with interface restrictions, typically in a libvirt environment.
- Determine the IP address and port (usually 53) of the dnsmasq server.
- Craft a TCP-based DNS query with a spoofed source IP address, targeting the dnsmasq server.
- Send the query to the dnsmasq server from a prohibited interface (i.e., an interface that should be blocked by configuration).
- Observe that dnsmasq processes the query and generates a response, despite the interface restriction.
- Repeat the process with multiple spoofed queries to amplify traffic and cause network congestion or resource exhaustion.
- Monitor the impact on DNS resolution and network performance to confirm the denial of service.
Indicators of compromise
- Unusual spikes in TCP traffic on port 53, especially from unexpected source IPs.
- DNS query logs showing responses to queries from interfaces that should be prohibited.
- High CPU or memory usage on the dnsmasq server.
- Network monitoring alerts indicating traffic amplification patterns.
- Firewall logs showing inbound TCP connections to port 53 from disallowed sources.
- Anomalous DNS response sizes compared to query sizes.
- EDR alerts on the host running dnsmasq for unusual network activity.
- Correlation with known DDoS reflection patterns involving DNS.
Mitigation and workarounds
- Upgrade dnsmasq to version 2.66test2 or later, which contains the complete fix for both UDP and TCP query handling.
- Apply vendor patches from your Linux distribution (Debian, Ubuntu, Gentoo) as soon as they are available.
- As a temporary workaround, restrict network access to dnsmasq using firewall rules to only allow queries from trusted interfaces and IP addresses.
- Disable TCP-based DNS queries if not required, by configuring dnsmasq to only listen on UDP.
- Monitor network traffic for signs of amplification and implement rate limiting on DNS responses.
- Review libvirt configurations to ensure interface restrictions are correctly enforced.
- Consider using a separate DNS resolver for untrusted networks to minimize exposure.
Community reactions
The security community acknowledged CVE-2013-0198 as a follow-up to CVE-2012-3411, highlighting the importance of thorough fixes. Vendors and distribution maintainers quickly released patches after disclosure. Discussions on mailing lists and forums focused on the incomplete fix and the need for comprehensive testing of security patches. Some security researchers noted the potential for abuse in DDoS amplification attacks, emphasizing the need for network-level mitigations. The vulnerability was rated as medium severity, but its EPSS percentile of 85.3 indicates a high likelihood of exploitation in the wild, prompting defenders to prioritize patching.
Additional resources
References
- http://www.mandriva.com/security/advisories?name=MDVSA-2013:072
- http://www.openwall.com/lists/oss-security/2013/01/18/2
- http://www.openwall.com/lists/oss-security/2013/01/18/7
- http://www.thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=commitdiff%3Bh=22ce550e5346947a12a781ed0959a7b1165d0dc6
- https://bugzilla.redhat.com/show_bug.cgi?id=894486
- http://www.mandriva.com/security/advisories?name=MDVSA-2013:072
- http://www.openwall.com/lists/oss-security/2013/01/18/2
- http://www.openwall.com/lists/oss-security/2013/01/18/7
- http://www.thekelleys.org.uk/gitweb/?p=dnsmasq.git%3Ba=commitdiff%3Bh=22ce550e5346947a12a781ed0959a7b1165d0dc6
- https://bugzilla.redhat.com/show_bug.cgi?id=894486
Intelligence is provided for awareness and triage. Validate exposure in your own environment before prioritising remediation.