The remote dnsmasq server is running a version prior to 2.66test2. It is, therefore, affected by a denial of service vulnerability in libvirtd due to improper parsing of malformed network packets. An unauthenticated, remote attacker can exploit this to cause an amplification of a large amount of DNS queries, resulting in a denial of service condition.

Note that this vulnerability exists due to an incomplete fix for CVE-2012-3411.

The remote NewStart CGSL host, running version CORE 5.04 / MAIN 5.04, has dnsmasq packages installed that are affected by multiple vulnerabilities:

  - The DNS protocol, as implemented in (1) BIND 8 and 9 before 9.5.0-P1, 9.4.2-P1, and 9.3.5-P1; (2)     Microsoft DNS in Windows 2000 SP4, XP SP2 and SP3, and Server 2003 SP1 and SP2; and other implementations     allow remote attackers to spoof DNS traffic via a birthday attack that uses in-bailiwick referrals to     conduct cache poisoning against recursive resolvers, related to insufficient randomness of DNS transaction     IDs and source ports, aka DNS Insufficient Socket Entropy Vulnerability or the Kaminsky bug.
    (CVE-2008-1447)

  - Heap-based buffer overflow in the tftp_request function in tftp.c in dnsmasq before 2.50, when --enable-     tftp is used, might allow remote attackers to execute arbitrary code via a long filename in a TFTP packet,     as demonstrated by a read (aka RRQ) request. (CVE-2009-2957)

  - The tftp_request function in tftp.c in dnsmasq before 2.50, when --enable-tftp is used, allows remote     attackers to cause a denial of service (NULL pointer dereference and daemon crash) via a TFTP read (aka     RRQ) request with a malformed blksize option. (CVE-2009-2958)

  - Dnsmasq before 2.66test2, when used with certain libvirt configurations, replies to queries from     prohibited interfaces, which allows remote attackers to cause a denial of service (traffic amplification)     via spoofed TCP based DNS queries. NOTE: this vulnerability exists because of an incomplete fix for     CVE-2012-3411. (CVE-2013-0198)

  - A flaw was found in dnsmasq before version 2.83. When getting a reply from a forwarded query, dnsmasq     checks in the forward.c:reply_query() if the reply destination address/port is used by the pending     forwarded queries. However, it does not use the address/port to retrieve the exact forwarded query,     substantially reducing the number of attempts an attacker on the network would have to perform to forge a     reply and get it accepted by dnsmasq. This issue contrasts with RFC5452, which specifies a query's     attributes that all must be used to match a reply. This flaw allows an attacker to perform a DNS Cache     Poisoning attack. If chained with CVE-2020-25685 or CVE-2020-25686, the attack complexity of a successful     attack is reduced. The highest threat from this vulnerability is to data integrity. (CVE-2020-25684)

  - A flaw was found in dnsmasq before version 2.83. When getting a reply from a forwarded query, dnsmasq     checks in forward.c:reply_query(), which is the forwarded query that matches the reply, by only using a     weak hash of the query name. Due to the weak hash (CRC32 when dnsmasq is compiled without DNSSEC, SHA-1     when it is) this flaw allows an off-path attacker to find several different domains all having the same     hash, substantially reducing the number of attempts they would have to perform to forge a reply and get it     accepted by dnsmasq. This is in contrast with RFC5452, which specifies that the query name is one of the     attributes of a query that must be used to match a reply. This flaw could be abused to perform a DNS Cache     Poisoning attack. If chained with CVE-2020-25684 the attack complexity of a successful attack is reduced.
    The highest threat from this vulnerability is to data integrity. (CVE-2020-25685)

  - A flaw was found in dnsmasq before version 2.83. When receiving a query, dnsmasq does not check for an     existing pending request for the same name and forwards a new request. By default, a maximum of 150     pending queries can be sent to upstream servers, so there can be at most 150 queries for the same name.
    This flaw allows an off-path attacker on the network to substantially reduce the number of attempts that     it would have to perform to forge a reply and have it accepted by dnsmasq. This issue is mentioned in the     Birthday Attacks section of RFC5452. If chained with CVE-2020-25684, the attack complexity of a     successful attack is reduced. The highest threat from this vulnerability is to data integrity.
    (CVE-2020-25686)

  - An issue was discovered in Dnsmasq before 2.90. The default maximum EDNS.0 UDP packet size was set to 4096     but should be 1232 because of DNS Flag Day 2020. (CVE-2023-28450)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

Updated dnsmasq packages fix security vulnerabilities :

When dnsmasq before 2.63 is used in conjunctions with certain configurations of libvirtd, network packets from prohibited networks (e.g. packets that should not be passed in) may be sent to the dnsmasq application and processed. This can result in DNS amplification attacks for example (CVE-2012-3411).

This update adds a new option --bind-dynamic which is immune to this problem.

Updated dnsmasq packages fix security vulnerabilities (CVE-2013-0198) :

This update completes the fix for CVE-2012-3411 provided with dnsmasq-2.63. It was found that after the upstream patch for CVE-2012-3411 issue was applied, dnsmasq still :

  - replied to remote TCP-protocol based DNS queries (UDP     protocol ones were corrected, but TCP ones not) from     prohibited networks, when the --bind-dynamic option was     used,

  - when --except-interface lo option was used dnsmasq     didn't answer local or remote UDP DNS queries, but still     allowed TCP protocol based DNS queries,

  - when --except-interface lo option was not used local /     remote TCP DNS queries were also still answered by     dnsmasq.

This update fix these three cases.

From dnsmasq's CHANGELOG :

Add code to make behaviour for TCP DNS requests that same as for UDP requests, when a request arrives for an allowed address, but via a banned interface. This change is only active on Linux, since the relevant API is missing (AFAIK) on other platforms.

  - dnsmasq now answers local queries if --except-interface     lo is used (libvirt's use case).

  - dnsmasq is now built with $RPM_OPT_FLAGS, $RPM_LD_FLAGS     explicitly.

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote host is affected by the vulnerability described in GLSA-201406-24 (Dnsmasq: Denial of Service)

    When used with certain libvirt configurations Dnsmasq replies to queries       from prohibited interfaces.
  Impact :

    A remote attackers can cause a Denial of Service via spoofed TCP based       DNS queries.
  Workaround :

    There is no known workaround at this time.

ID	Name	Product	Family	Published	Updated	Severity
87595	dnsmasq < 2.66test2 libvirtd TCP Network Packet Parsing Response DNS Amplification DoS	Nessus	DNS	12/22/2015	7/10/2018	medium
193540	NewStart CGSL CORE 5.04 / MAIN 5.04 : dnsmasq Multiple Vulnerabilities (NS-SA-2024-0011)	Nessus	NewStart CGSL Local Security Checks	4/18/2024	4/19/2024	medium
66086	Mandriva Linux Security Advisory : dnsmasq (MDVSA-2013:072)	Nessus	Mandriva Local Security Checks	4/20/2013	1/6/2021	medium
64592	Fedora 18 : dnsmasq-2.65-4.fc18 (2013-1357)	Nessus	Fedora Local Security Checks	2/13/2013	1/11/2021	medium
64672	Fedora 17 : dnsmasq-2.65-4.fc17 (2013-1320)	Nessus	Fedora Local Security Checks	2/19/2013	1/11/2021	medium
76226	GLSA-201406-24 : Dnsmasq: Denial of Service	Nessus	Gentoo Local Security Checks	6/26/2014	1/6/2021	medium

Detections

Analytics

Plugins Search

medium

medium

medium

medium

medium

medium