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.

CVE Severity Introduced Exposure Nature of Flaw CVE-2017-14491 Critical All Versions DNS Heap buffer overflow CVE-2017-14492 Critical 2.60 - 2.66 IPv6 RA Heap buffer overflow CVE-2017-14493 Critical 2.60 - 2.66 DHCPv6 Stack buffer overflow CVE-2017-14494 Important 2.60 - 2.66 DHCPv6 Information leak CVE-2017-14495 Important 2.76 EDNS0 Memory exhaustion CVE-2017-14496 Important 2.76 EDNS0 Segmentation fault CVE-2017-13704 Important 2.77 DNS Segmentation fault

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 Configuration options that render dnsmasq vulnerable CVE-2017-14492 enable-ra slaac ra-only ra-names ra-advrouter ra-stateless CVE-2017-14495 add-mac add-cpe-id add-subnet CVE-2017-14496 add-mac add-cpe-id add-subnet

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