dnsmasq: Multiple Critical and Important vulnerabilities

Red Hat Product Security has been made aware of several vulnerabilities affecting dnsmasq.  Three of these vulnerabilities (CVE-2017-14491, CVE-2017-14492, and CVE-2017-14493) have been rated as Critical, while the remaining four (CVE-2017-14494, CVE-2017-14495, CVE-2017-14496, and CVE-2017-13704) have been rated as Important.  These issues were publicly disclosed on Monday, October 2nd, 2017.

Background Information

dnsmasq is a popular lightweight DNS and DHCP server, often used in home networks and cloud environments as a caching DNS stub resolver and to manage DHCP leases.  It is provided in Red Hat Enterprise Linux, where it is used directly by applications including libvirt, and in a number of layered products.  Many vendors prefer dnsmasq for its low resource consumption, simple configuration and flexibility.  While it is not recommended for large-scale deployments or as an authoritative name server, it is commonly used as a local caching resolver and for small-scale LAN and cloud environments.

Vulnerability Details

Six of these vulnerabilities were discovered and disclosed under embargo by Google, and the seventh (CVE-2017-13704) was already public and fixed in the dnsmasq git repository.  Some of these affected DHCP functionality while others affected DNS, with impacts ranging from a crash, unbounded resource consumption up to potential code execution.  All seven could be triggered by malicious users on the network.

Some of these vulnerabilities require particular options to be enabled to render dnsmasq vulnerable.  These options can appear on the command line or in a configuration file:

CVE-2017-14491: Critical

This is the worst vulnerability, and the only one that affected all versions of dnsmasq in supported Red Hat products.  To trigger this flaw, an attacker would need to control a malicious domain (eg, evil.com) and send DNS requests to dnsmasq that would cause it to cache replies from that domain.  By carefully constructing DNS requests and responses, dnsmasq could be made to overflow an internal buffer on the heap, using content influenced by the attacker.  This could potentially be used to achieve code execution.

CVE-2017-14492 and CVE-2017-14493: Critical

These two vulnerabilities exist in IPv6/DHCPv6 functionality, and are also both buffer overflows (heap and stack, respectively).  Either could potentially be used to achieve code execution, although the use of gcc's Stack Smashing Protector (enabled in Red Hat Enterprise Linux 5, 6 and 7) should effectively reduce the impact of CVE-2017-14493 to only a crash.

A dnsmasq instance would only be vulnerable to these if DHCP was enabled and it was bound to an IPv6 interface.  Further, the attacker would need to be in a position to send crafted DHCPv6 or IPv6 Router Advertisement messages to the server - usually requiring administrator (root) privileges on a host on the local network.

Since DHCPv6 and IPv6 Router Advertisement support were only introduced after dnsmasq 2.60, versions earlier than this are not affected by this flaw.  We have not determined what exact release introduced the vulnerable code, other than that it was prior to dnsmasq version 2.66 (shipped in Red Hat Enterprise Linux 7.2 and 7.3).

CVE-2017-14494: Important

This vulnerability also only exists in DHCPv6, and allows an attacker to cause dnsmasq to read out of bounds, revealing portions of the contents of its own memory in the DHCPv6 response packet.  While it did not seem possible to crash or gain control of dnsmasq, the information revealed could be used in conjunction with another flaw to bypass mitigations or, potentially, be sensitive in its own right.

Like the previous two vulnerabilities, this was first introduced in a version between 2.60 and 2.66 inclusive, and fixed in 2.78.  Versions prior to 2.59, as provided with Red Hat Enterprise Linux 6 and 5, are not affected.

CVE-2017-14495: Important

This vulnerability was in EDNS0 functionality (RFC-2671).  It manifested as a memory leak: when constructing EDNS0 portions of replies under certain conditions, dnsmasq would allocate an intermediate data structure and then fail to free it.  By sending a carefully selected sequence of DNS requests, an attacker could cause dnsmasq to allocate several kilobytes for each subsequent request, eventually consuming all available memory and crashing.

The affected code was introduced in dnsmasq version 2.76; Red Hat Enterprise Linux 7.4 was affected, but earlier major and minor versions were not.

CVE-2017-14496: Important

Also in EDNS0 code, this vulnerability is a sign-confusion flaw which would lead to memcpy() being called with a negative size argument.  memcpy() would interpret this as a very large positive integer and try to copy a larger region than was mapped, leading to a crash.  By exploiting this flaw, an attacker could deny service to all other processes or hosts reliant on dnsmasq as a resolver.

This flaw was also introduced in dnsmasq version 2.76; Red Hat Enterprise Linux 7.4 was affected, but earlier major and minor versions were not.

CVE-2017-13704: Important

Similar to CVE-2017-14496, the flaw was sign confusion, this time in the size argument given to memset(), and would lead to a crash.  The vulnerable memset() calls were introduced in dnsmasq 2.77 as a hardening measure, to zero buffers where response packets would be constructed, such that information leaks similar to CVE-2017-14494 would be avoided.  These calls to memset() were strictly a defensive measure as no such information leaks were previously known.  Following the discovery that these could go wrong, appropriate checks on the arguments to memset() were introduced.

This flaw was introduced in version 2.77 and fixed prior to 2.78.  No Red Hat products were affected.

Acknowledgements

Red Hat would like to thank Felix Wilhelm (Google Security Team), Fermin J. Serna (Google Security Team), Gabriel Campana (Google Security Team), Kevin Hamacher (Google Security Team), Ron Bowes (Google Security Team) for reporting this flaw.

Additional References

https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html

Impacted Products

Red Hat Product Security has rated this update as having a security impact of Critical.

The following Red Hat product versions are impacted:

• Red Hat Enterprise Linux 7

• Red Hat Enterprise Linux 6

• Red Hat Enterprise Linux 5

Attack Description and Impact

Attackers with network access to an instance of dnsmasq could potentially carry out these attacks. This includes client machines or nodes on a LAN or WAN where dnsmasq is used as a caching resolver (as is optional on Red Hat Enterprise Linux Atomic Host) as well as users of virtual machines (such as those hosted by libvirt, Red Hat OpenStack Platform and Red Hat OpenShift, which use dnsmasq as part of network provisioning).

CVE-2017-14491 potentially impacts all uses of dnsmasq, while the other vulnerabilities require special conditions such as IPv6, DHCP being enabled or special options in the case of CVE-2017-11491, CVE-2017-14495, and CVE-2017-14496 (see table in the Overview tab).

Privileges of the running dnsmasq are futher restricted by SELinux policy, when SELinux is enabled, which reduces the impact of compromise and helps avoid full guest to host escapes. However, taking over dnsmasq's DNS and DHCP functionality is a significant impact even if full host compromise is not possible, as it could potentially affect other guests (virtual machines or containers) hosted in the same environment.

Diagnose your vulnerability