RHSB-2021-001 DNSpooq - Multiple vulnerabilities within dnsmasq (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686, CVE-2020-25687)

Executive summary

Red Hat is aware of multiple issues within dnsmasq that have been branded as DNSpooq. Dnsmasq is a lightweight tool designed to provide network services including DNS and DHCP for private networks and virtualization environments. These issues are in the Domain Name System (DNS) service provided by dnsmasq and could be used by a remote attacker, with some degree of control over a dnsmasq client system, to redirect users to incorrect sites or to execute code on the machine which is hosting dnsmasq.

Two of these flaws (CVE-2020-25681 and CVE-2020-25682) have a severity impact rating of Important due to the ability to remotely execute code on a dnsmasq machine. CVE-2020-25683, CVE-2020-25684, CVE-2020-25685, CVE-2020-25686, and CVE-2020-25687 have a severity impact rating of Moderate .

CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687 requires DNSSEC to be compiled and enabled in the dnsmasq configuration. As a result, the following Red Hat product versions are impacted when using non-default configuration:

• Red Hat Enterprise Linux 8

CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686 may allow an attacker to poison the DNS cache and redirect victim users to incorrect sites. They impact the following Red Hat product versions:

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 8

The following Red Hat products are potentially impacted as they pull dnsmasq from the Red Hat Enterprise Linux channel. Please ensure that the underlying Red Hat Enterprise Linux dnsmasq package is current and reference the libvirt use case for more information.

• Red Hat OpenStack Platform 10

• Red Hat OpenStack Platform 13

• Red Hat Virtualization 4.3

• Red Hat Virtualization 4.4

• Red Hat OpenShift Container Platform 3.11

To determine if your system is currently vulnerable to these flaws, see the Diagnose section below.

Technical summary

These seven issues in dnsmasq are divided into two groups:

• Flaws in the way dnsmasq matches incoming DNS replies with previously forwarded queries (CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686).

• Flaws that are composed of buffer overflows in the code that prepares DNSSEC data for validation (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687).

To exploit this second set of vulnerabilities, an attacker requires the collaboration of a dnsmasq client or other ways to make a client start a series of DNS queries to dnsmasq for an attacker-controlled domain.

The first group of flaws can mainly be used to easily perform a DNS cache poisoning attack, which would impact all clients that use dnsmasq as a DNS server, providing them incorrect name resolutions for the poisoned entries. When the flaws are chained together, the attack can be performed in as short as a few minutes.

The second group of vulnerabilities requires DNSSEC to be enabled in dnsmasq and they can be triggered before DNSSEC data is validated by sending a crafted response to an open forwarded query.

The end result of the successful exploit varies based on the vulnerability, as well. For CVE-2020-25681 and CVE-2020-25682, a remote code execution could occur on the host machine and, thus, have an Important severity impact rating. CVE-2020-25683 and CVE-2020-25687 only result in a crash of the dnsmasq service and have a severity impact rating of Moderate.

Please be aware that even though dnsmasq is not started by the user, it can be automatically run by libvirt to provide DNS service to guest virtual machines. Additionally, NetworkManager can be configured to use dnsmasq to provide DNS to the system.

Reference the Background section for more context about the flaws.

Mitigation

The impact of CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686 can be reduced by disabling the dnsmasq cache by adding `--cache-size=0` when calling dnsmasq or by adding a line with `cache-size=0` to the dnsmasq configuration file (/etc/dnsmasq.conf by default).

When using Red Hat Enterprise Linux 8.3 with libvirt through a virt:rhel module, use `virsh net-edit <network-name>` and reference https://libvirt.org/formatnetwork.html#elementsNamespaces to add the suggested option `cache-size=0`.

When using versions of Red Hat Enterprise Linux prior to version 8.3, there is no way to customize the dnsmasq configuration generated by libvirt. If dnsmasq is being run through NetworkManager, create a new file in /etc/NetworkManager/dnsmasq.d/ and add `cache-size=0` to it.

In all cases, by disabling the cache, you may experience a performance loss in your environment due to all DNS queries being forwarded to the upstream servers. Please evaluate if the mitigation is appropriate for the system’s environment before applying.

The only known way to mitigate CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687 is to disable DNSSEC altogether, by removing the `--dnssec` command line option or the `dnssec` option from dnsmasq configuration file.

We recommend applying dnsmasq updates as soon as they become available.

Technical details

CVE-2020-25681

A heap-based buffer overflow was discovered in the way RRSets are sorted before validating with DNSSEC data. An attacker on the network, who can forge DNS replies such as that they are accepted as valid, could use this flaw to cause a buffer overflow with arbitrary data in a heap memory segment, possibly executing code on the machine.

CVE-2020-25682

A buffer overflow vulnerability was discovered in the way dnsmasq extract names from DNS packets before validating them with DNSSEC data. An attacker on the network, who can create valid DNS replies, could use this flaw to cause an overflow with arbitrary data in a heap-allocated memory, possibly executing code on the machine. The flaw is in the rfc1035.c:extract_name() function, which writes data to the memory pointed by name assuming MAXDNAME*2 bytes are available in the buffer. However, in some code execution paths, it is possible extract_name() gets passed an offset from the base buffer, thus reducing, in practice, the number of available bytes that can be written in the buffer.

CVE-2020-25683

A heap-based buffer overflow was discovered in dnsmasq when DNSSEC is enabled and before it validates the received DNS entries. A remote attacker, who can create valid DNS replies, could use this flaw to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in get_rdata() and cause a crash in dnsmasq, resulting in a denial of service.

CVE-2020-25684

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.

CVE-2020-25685

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.

CVE-2020-25686

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.

CVE-2020-25687

A heap-based buffer overflow was discovered in dnsmasq when DNSSEC is enabled and before it validates the received DNS entries. This flaw allows a remote attacker, who can create valid DNS replies, to cause an overflow in a heap-allocated memory. This flaw is caused by the lack of length checks in rfc1035.c:extract_name(), which could be abused to make the code execute memcpy() with a negative size in sort_rrset() and cause a crash in dnsmasq, resulting in a denial of service.

Background

Domain Name System (DNS) is mainly used to translate domain names (for example, www.example.com) to IP addresses (for example 127.0.0.1 and 2001:DB8::1). It is organized as a distributed system, with no single node knowing all the domains and translations. Resolving a single name may require multiple queries and responses from several servers until the name server that knows about the requested name is reached. This whole process is known as the DNS resolution process.

DNS has several security limitations, and in particular, it cannot guarantee any of the involved servers or other external attackers would not provide forged answers. It mainly uses a random 16-bit identifier in the DNS reply/query and a random UDP source port as a way to prevent external attackers from hijacking the communication. DNSSEC was developed to add a layer on top of DNS to provide origin authentication and integrity assurance to DNS data. When used it associates a signature with the actual DNS data that can be verified by other systems to make sure that the provided answer actually comes from the authoritative server for that domain and that it was not forged by someone else. If applied, DNSSEC validation would prevent DNS Cache Poisoning attacks, however, its adoption is not widespread yet.

Dnsmasq is a lightweight tool that provides network infrastructure for small networks and in particular, it provides DNS and DHCP services. Its DNS service is mainly used as a forwarder, which gets DNS queries from clients, forwards them to a set of pre-configured upstream DNS servers and then caches the replies so that the next time the same query is done by the same or another client, a reply can be returned immediately without asking the upstream server again. It can also be configured to perform DNSSEC validation.

CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686 can be used by an attacker, who also has some sort of control over a dnsmasq client, to craft DNS replies and trick dnsmasq into accepting them as if they would come from the pre-configured upstream DNS servers. When the cache is enabled (the default behavior), these incorrect replies are cached and served to other clients as well, redirecting them to potentially malicious sites. This issue is known as a DNS Cache Poisoning attack. These flaws substantially reduce the number of attempts an attacker has to make to guess the 16-bit identifier and the specific UDP port used for a particular DNS query. Considering the attack is not deterministic and requires some time to guess the right combination of values, an attacker needs a dnsmasq client to start performing many DNS queries to an attacker-chosen domain (for example, a victim user visits a malicious web site that triggers the DNS resolution process through the browser, the attacker has control over a client system or can compromise one).

When dnsmasq is configured to use DNSSEC, it becomes vulnerable to CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687. These flaws can be used by a remote attacker, who also has some sort of control over a dnsmasq client, to remotely execute code on the system that is running dnsmasq or to crash it, causing a denial of service for dnsmasq clients, which would not be able to resolve domain names anymore.

Product impact

Red Hat Enterprise Linux 8

By default, dnsmasq systemd service is disabled and NetworkManager is not configured to use it.

The versions of dnsmasq as shipped with Red Hat Enterprise Linux 8 are affected by all CVEs announced in this article. However, in its default configuration, Red Hat Enterprise Linux 8 does not enable DNSSEC and thus it is not impacted by CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687.

Red Hat Enterprise Linux 7 / Red Hat Enterprise Linux 6

By default, dnsmasq systemd service is disabled and NetworkManager is not configured to use it.

The versions of dnsmasq as shipped with Red Hat Enterprise Linux 6, and 7 are only affected by CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686.

Red Hat Enterprise Linux 6, and 7 are not affected by the other flaws, due to DNSSEC not being compiled in the dnsmasq packages.

Libvirt use case

Unless explicitly disabled, dnsmasq is used to provide DNS services to libvirt guests, using the system resolvers as upstream DNS servers. An attacker with control over a guest system or with the ability to trick a guest system into performing multiple DNS queries to an attacker-controlled domain, would be able to use CVE-2020-25684, CVE-2020-25685, and CVE-2020-25686 to poison the dnsmasq cache and affect all guests connected to the same virtual network. Unless DNSSEC is manually configured, dnsmasq as used in libvirt is not vulnerable to CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, and CVE-2020-25687.

Service impact

For all OpenShift v3 clusters, including: Red Hat OpenShift Online, OpenShift Dedicated, Microsoft Azure Red Hat OpenShift:

Dnsmasq is in use in OpenShift Dedicated v3. The dnsmasq used in OpenShift v3 clusters is shipped through the Red Hat Enterprise Linux 7 package, v3 clusters are not affected by the DNSSEC flaws (CVE-2020-25681, CVE-2020-25682, CVE-2020-25683, CVE-2020-25687).

For non-DNSSEC flaws (CVE-2020-25684, CVE-2020-25685, CVE-2020-25686), OpenShift Dedicated 3 services are affected, since they are using the package shipped by Red Hat Enterprise Linux 7. Each node uses dnsmasq and there is no protection that may prevent an attacker from poisoning the Node’s DNS cache.

Red Hat is taking measures to update the Services to mitigate this vulnerability.  In the interim, to prevent cache poisoning attack by exploiting the vulnerabilities, customers using dnsmasq can explicitly set --cache-size=0 when calling dnsmasq.  If the Service is running dnsmasq through libvirt (an open source API), customers can use virsh net-edit <network-name>  to update cache-size=0. 

For all OpenShift v4 clusters, including: OpenShift Dedicated cluster:

OpenShift Dedicated v4 uses the DNS operator (which uses CoreDNS) instead of dnsmasq. The OpenShift v4 clusters are not affected by the dnsmasq flaws. We have verified there are no clusters in v4 that are using dnsmasq.

Affected Red Hat products by CVE

Updates for affected products

Red Hat customers running affected versions of these Red Hat products are strongly recommended to update as soon as erratas are available. Customers are urged to apply the available updates immediately and enable the mitigations as they feel appropriate.

[1] Advisory/Update link will be added once updates are live.

[2] What is the Red Hat Enterprise Linux Extended Update Support (EUS) Subscription?

[3] What is Advanced mission critical Update Support (AUS)?

[4] What is the Red Hat Enterprise Linux SAP Solutions subscription?

Potentially Impacted Products and Containers

The following products and containers consume affected packages from another product.  While Red Hat's Containers are not directly impacted by these issues, their security relies upon the integrity and updates of the base image (like updates to RHEL packages). Red Hat recommends that you use the most recent versions of your container images. The Container Health Index, part of the Red Hat Container Catalog, can always be used to verify the security status of Red Hat containers

Diagnose

A vulnerability detection script has been developed to determine if your system is currently vulnerable to this flaw. To verify the authenticity of the script, you can download the detached GPG signature as well. Instructions on how to use GPG signatures for verification are available on the Customer Portal.

FAQ

Q: Is my system vulnerable to these flaws if dnsmasq is used to provide DNS on a private network?

A: An attacker needs to submit many DNS queries from within the private network to the vulnerable dnsmasq instance, because the attack requires some guessing to bypass basic DNS protections. DNS queries might be triggered in several ways ranging from having full control over a system on the network to tricking a victim user connected on the network into opening an email or a website. With sufficient numbers of DNS queries, these flaws could be exploited, even on a private network.

Q: Can these flaws be used to perform a guest-to-host escape if my system uses libvirt?

A: The attacker requires some sort of collaboration from one of the guests to start an attack that uses these flaws. If the attacker can start multiple DNS queries to dnsmasq from a guest system, it would be possible to abuse the flaws announced in this article to poison its cache. If DNSSEC was manually configured in dnsmasq as used by libvirt (non default configuration) it would be possible to also execute code or crash the dnsmasq server in the host machine.

Q: What steps after upgrading the dnsmasq package are necessary to ensure the system is not vulnerable?

A: All running instances of dnsmasq need to be restarted. The most straightforward way is restarting all machines where dnsmasq is running, including virtualization hosts and guests. As dnsmasq instances can be run by libvirt and other system components, restarting these components is necessary. Restarting these instances without rebooting requires different procedures for different components. For instance, all libvirt networks using dnsmasq must be restarted and re-attached to the respective virtual machines. This is a potentially complicated and production-breaking procedure and must be tailored and tested for each environment separately.

Q: Do I need to apply the mitigation steps or update if the dnsmasq package is installed on my system but it is not running (or enabled)?

A: If you have the dnsmasq package installed on your system then you are at risk of being vulnerable or becoming vulnerable to these flaws if dnsmasq is enabled later. We suggest you apply the mitigation steps explained in the relative section and recommend to update the dnsmasq package as soon as possible.

Acknowledgements

Red Hat thanks Moshe Kol and Shlomi Oberman (JSOF) for reporting this vulnerability.

References

JSOF research article on DNSpooq

How to use GPG to verify signed content from Product Security