dnsmasq: Multiple Critical and Important vulnerabilities

Updated -
Status
Resolved
Impact
Critical

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.

CVESeverityIntroducedExposureNature of Flaw
CVE-2017-14491CriticalAll VersionsDNSHeap buffer overflow
CVE-2017-14492Critical2.60 - 2.66IPv6 RAHeap buffer overflow
CVE-2017-14493Critical2.60 - 2.66DHCPv6Stack buffer overflow
CVE-2017-14494Important2.60 - 2.66DHCPv6Information leak
CVE-2017-14495Important2.76EDNS0Memory exhaustion
CVE-2017-14496Important2.76EDNS0Segmentation fault
CVE-2017-13704Important2.77DNSSegmentation 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:

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

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

Determine if your system is vulnerable

Determine if your system is vulnerable. Use the detection script below to determine if your system is currently vulnerable to this flaw. To verify the legitimacy of the script, you can download the detached GPG signature as well. The current version of the script is 1.0.

Take Action

All Red Hat customers running affected versions of dnsmasq are strongly recommended to update as soon as patches are available. While mitigations exist for some of these vulnerabilities (such as disabling IPv6), there are no mitigations to protect against all of them together and customers are urged to apply the updates immediately.

Updates for Affected Products

ProductPackageAdvisory/Update
Red Hat Enterprise Linux 7dnsmasqRHSA-2017:2836
Red Hat Enterprise Linux 7.2 and 7.3 Extended Update Support**dnsmasqRHSA-2017:2837
Red Hat Enterprise Linux 6dnsmasqRHSA-2017:2838
Red Hat Enterprise Linux 6.7 Extended Update Support**dnsmasqRHSA-2017:2839
Red Hat Enterprise Linux 6.5 and 6.6 Advanced Update Support***, Telco Extended Update Support****dnsmasqRHSA-2017:2839
Red Hat Enterprise Linux 6.2 and 6.4 Advanced Update Support***dnsmasqRHSA-2017:2839
Red Hat Enterprise Linux 5 Extended Lifecycle Support*dnsmasqRHSA-2017:2840
Red Hat Enterprise Linux 5.9 Advanced Update Support***dnsmasqRHSA-2017:2841

*An active ELS subscription is required for access to this patch.

Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active ELS subscription.

**An active EUS subscription is required for access to this patch.

Please contact Red Hat sales or your specific sales representative for more information if your account does not have an active EUS subscription.

What is the Red Hat Enterprise Linux Extended Update Support Subscription?

***An active AUS subscription is required for access to this patch in RHEL AUS.

****An active TUS subscription is required for access to this patch in RHEL TUS.

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

8 Comments

Subscriber exclusive content

A Red Hat subscription provides unlimited access to our knowledgebase of over 48,000 articles and solutions.

Current Customers and Partners

Log in for full access

Log In

Links on the resolve page don't work: e.g. https://errata.devel.redhat.com/advisory/30609

Hi Mattison - You may need to refresh the page. We've validated that all the links on the Resolve tab to the RHSAs are functional. Let us know if you continue to have an issue accessing the errata and we can do some additional troubleshooting.

I have something on a flash someone will want to see

Thanks to the Red Hat Security team members for providing the dnsmasq package update in such a short time ... great job - well done ! :)

Hi - Could you please tell me if I am vulnerable to these flaws as I have installed dnsmasq in several VMware VM running RHEL, but I do not have neither a DNS server or cache nor DHCP server?

I'm afraid you can not expect any useful reply here, as we don't know enough about your systems and infrastructure to know why you have dnsmasq installed, and how and if it's used. If it's running, you should patch. If it's not running and not needed, and you don't want to patch, consider removing instead.

We only use AD DNS and we don't use any Linux DHCP server, though our servers don't have latest version of dnsmasq version, do we have apply the fix patch or we are OK with this vulnerabilities? thank

See the answer to the previous question. If you want to be sure, either patch or remove dnsmasq. Don't expect any definite response based on the limited information provided.

Close

Welcome! Check out the Getting Started with Red Hat page for quick tours and guides for common tasks.