IoT
Dnsmasq: A Reality Check and Remediation Practices
Google Security researchers identified seven vulnerabilities that can allow a remote attacker to execute code on, leak information from, or crash a device running a Dnsmasq version earlier than 2.78, if configured with certain options.
Save to Folio
Updated on October 10, 2017, 7:30 PM PDT to add further Trend Micro solutions.
Dnsmasq is the de-facto tool for meeting the DNS/DHCP requirements of small servers and embedded devices. Recently, Google Security researchers identified seven vulnerabilities that can allow a remote attacker to execute code on, leak information from, or crash a device running a Dnsmasq version earlier than 2.78, if configured with certain options.
Based on Censys and Shodan data, we found that about one million publicly accessible hosts are running a Linux distribution that likely includes Dnsmasq, and are exposing a DNS service (port 53) on the public internet. These hosts, under the circumstances explained in this post, are potentially vulnerable to all or some of these vulnerabilities. This estimate does not include hosts running Dnsmasq that aren't exposed to the public internet.
Given Dnsmasq's ubiquity and the well-known difficulty in patching embedded systems, this post covers:
- an analysis of the significant conditions that must exist for a vulnerable installation to be exploitable,
- a checklist on how to verify whether a Dnsmasq installation is vulnerable and exploitable,
- a guide on how to secure such vulnerable installations.
The flowchart below serves as a quick guide for determining if an embedded system is vulnerable:
Figure 1. Steps for checking if your Dnsmasq deployment is potentially vulnerable, and suggested solutions (Click to enlarge)
What are the recent Dnsmasq vulnerabilities?First released around 2001, Dnsmasq has become an essential part of routers and IoT gateways because it provides a network's two most essential functions: DHCP and DNS. Its flexibility and lightweight footprint have made it a part of the classic embedded-Linux software combo, which usually includes BusyBox and DropBear. In other words, if an embedded-Linux device offers DNS/DHCP services and an SSH-accessible console, Dnsmasq, BusyBox, and DropBear are all likely to be present. Given the ubiquity of embedded systems, these three small software packages are becoming more and more critical.
Between September 24 and 25, Simon Kelley, the developer of Dnsmasq, pushed seven fixes to the Git repository to address seven vulnerabilities privately disclosed by Google Security researchers. These vulnerabilities could allow a remote attacker to execute code on, leak information from, or crash a running Dnsmasq service. Dnsmasq versions prior to 2.78 (released on October 2) are vulnerable, with those prior to 2.76 containing a more serious variant of one of these vulnerabilities that allows a remote attacker unrestricted code-execution capability.
Note that our examination does not include CVE-2017-13704.
Should I care about these vulnerabilities?Because of its flexibility, Dnsmasq is frequently used in a variety of networked hosts, from handheld devices, laptops, and small servers to IoT gateways and small-office/home routers running customized or vendor-supplied firmware, including those bundled by ISPs.
Because Dnsmasq is packaged with several OS distributions, it is up to these developers to release an update. For example, Alpine Linux users received the patched package right away, whereas users of OpenWrt-based devices (very popular in routers) either had to wait or put the patch in themselves. The fixes had not yet been added into the official OpenWrt distribution, which is understandable as these open source projects frequently rely only on the labors of volunteers.
Patching an embedded system such as a router is not exactly easy and without risk: users tend to wait for a security fix coming from the vendor, or from community-driven package repositories.
This means that many embedded devices are still running a vulnerable version of Dnsmasq. So, let’s look at embedded devices based on distributions such as OpenWrt and its derivatives (e.g., DD-WRT being the most popular one), or distributions including a Dnsmasq binary package distributed by the maintainer. How many of these devices are out there?
How widespread is Dnsmasq?We can't reliably count them, but we can provide a conservative estimate based on the number of devices using well-known open-source Linux distributions that likely include Dnsmasq. For this purpose, I used Censys and Shodan, the two largest indexes of devices with open ports on the internet.
Which Linux distributions make sense to use to get an estimate? We chose three distributions: OpenWrt, DD-WRT, and Tomato Firmware, which are commonly used in routers. Notably, OpenWrt is also used by some industrial-router manufacturers such as VirtualAccess and IntelliDesign.
Other distributions used for small systems, such as Raspbian (for Raspberry Pi computers) and other Debian derivatives are receiving security upgrades via Debian repositories, which have already merged the patch. The same holds for Alpine-based systems. This is not the case for the three distributions we chose.
I used the following Censys query to make a quick, high-level assessment:
("openwrt" OR "dd-wrt" OR "dnsmasq" OR "Tomato Firmware")
On October 4, the query returned 203,645 hosts, of which 4,408 directly expose a DNS service (port 53).
Without actively probing these hosts we can't be sure that they're running Dnsmasq, but there is evidence that supports this hypothesis. Given the breakdown of the top protocols exposed, we're most likely looking at router-like devices: HTTPS and HTTP for the web-based configuration user interface, Telnet and SSH for command-line based administration, FTP, and so on. These are all services that typically appear in a SOHO router.
| Protocol | Hosts | |
| 8080/http | 62,871 | 30.9% |
| 443/https | 58,881 | 28.9% |
| 80/http | 34,752 | 17.1% |
| 23/telnet | 15,308 | 7.5% |
| 22/ssh | 12,775 | 6.3% |
| Others | 19,058 | 9.3% |
| Total | 203,645 | 100.0% |
Table 1. Breakdown of the 203,645 devices potentially running Dnsmasq according to Censys scan data
The above query picks up hosts running OpenWrt, DD-WRT or Tomato (or containing the “dnsmasq” string in the network banners). Let’s take another view and narrow the scope to devices responding to requests on port 53. Adapting the query to Shodan’s syntax and semantics, as of October 9, we found 1,155,555 devices with port 53 open to the public internet (up from 1,087,600 as of October 4).
Figure 2. Heatmap of the 1,155,555 devices potentially running Dnsmasq with port 53 open (according to Shodan data as of October 9)
A vanilla Dnsmasq service will always report its version in the network banner, which is captured by Shodan. This allows us to obtain the breakdown of the versions. On a sample of 747,276 hosts (as much as Shodan let us download), we found 99.04% of these hosts with a “dnsmasq-<version number>” string. Only three of them had a patched Dnsmasq version (2.78).
| Hosts | Percentage | Dnsmasq version |
| 155,911 | 20.86% | 2.52 |
| 145,555 | 19.48% | 2.4 |
| 86,678 | 11.60% | 2.62 |
| 74,475 | 9.97% | 2.48 |
| 58,349 | 7.81% | 2.61 |
| 40,266 | 5.39% | 2.51 |
| 186,042 | 24.90% | Others |
Table 2. Breakdown of Dnsmasq versions
Assuming that these devices are running the vanilla versions of the respective distributions, they're all running an outdated—and thus potentially vulnerable—version of Dnsmasq.
Fortunately, we'll see that even a vulnerable version of Dnsmasq can be difficult to exploit.
Under which conditions the vulnerabilities are exploitable? First of all, all of the vulnerabilities (CVE-2017-14491 to 14496) assume the attacker is remote to the target device, which means that the attacker only needs to be able to send (and sometimes receive) network packets to/from the target device. Does it mean all of the devices we found were remotely exploitable? Let's look at the requirements to understand their impact better.
This table is meant to provide an operational checklist to complement the table provided by Google, which focuses on the vector and the impact of said vulnerabilities.
| CVE | Attacker must be able to | Dnsmasq is exploitable if | Options that trigger targeted feature |
| CVE-2017-14491 | control (the responses from) the upstream server | uses an upstream DNS server | -S, --local, --server=<upstream server> |
| CVE-2017-14492 | send packets to the target host | runs DHCPv6 service IPv6 Router Advertisement is enabled | -F, --dhcp-range=<IPv6 range> --enable-ra |
| CVE-2017-14493 | send packets to the target host | runs a DHCPv6 service | -F, --dhcp-range=<IPv6 range> |
| CVE-2017-14494 | send packets to the target host | runs a DHCPv6 service | -F, --dhcp-range=<IPv6 range> |
| CVE-2017-14495 | send packets to the target host | runs with extended DNS options | Any of --add-mac, --add-cpe-id, or --add-subnet |
| CVE-2017-14496 | send packets to the target host | runs with extended DNS options | Any of --add-mac, --add-cpe-id, or --add-subnet |
Table 3. Requirements of different vulnerabilities for exploitation
Attack scenario and requirements of CVE-2017-14491 exploitation
Figure 3. Attack scenario for CVE-2017-14491
The above diagram shows how CVE-2017-14491 can be exploited. The attacker must be able to receive forwarded DNS queries from the victim device or control the DNS responses of the queried domain. The responses will contain the exploit. It's an unusual scenario because the attacker must be able to configure the devices running Dnsmasq so that a device also under the attacker’s control can receive the queries.
The devices running Dnsmasq could either directly or indirectly participate in the attack. For example, the laptop (or the mobile device) could be running Dnsmasq configured to query the attacker-controlled upstream server. It could also query the DNS server running on the router, which, in turn, will query the malicious upstream server.
To this end, the attacker must exploit other vulnerabilities in the router, be able to manipulate the network routes to receive the DNS queries or use social engineering (by convincing the victim to click on a link to a URL hosted under a domain that the attacker controls) as a last-resort. With a non-vulnerable Dnsmasq deployment, the damage that can be done by an attacker is limited to manipulating the result of a DNS request. Instead, thanks to these recent vulnerabilities, an attacker that can receive forwarded DNS requests can execute arbitrary code on the target device.
To summarize, despite beginning with a heap overflow—a well-known vulnerability class—the conditions for successfully exploiting CVE-2017-14491 are not trivial. Even in the vulnerable versions of Dnsmasq, the memory overflow is limited to 2 bytes. Before Dnsmasq 2.76, the attacker had the freedom to control an unlimited amount of memory.
Attack scenario of CVE-2017-14492 to 14496
Figure 4. Attack scenario for CVE-2017-14492 to 14496. An attacker must be able to send network packets to the vulnerable devices, which must be configured with the options reported in the table above.
The above diagram shows the attack scenarios for CVE-2017-14492 through 14496. However, the requirements for attacking these vulnerabilities differ slightly.
Requirements for exploiting CVE-2017-14492, 14493, and 14494
To exploit these vulnerabilities, the attacker must be able to send network packets to the DHCP subsystem of the target host running Dnsmasq. In particular, triggering these vulnerabilities requires that the DHCPv6 service is enabled, which means that the host must be serving IPv6 configuration packets. In Dnsmasq, this translates to having the --dhcp-range option listing an IPv6 address range (e.g., "fd00::3,fd00::ff").
In addition, to exploit CVE-2017-14492, the Dnsmasq –enable-ra option (for IPv6 Router Advertisement) must be enabled. Although we can’t be certain whether or not the hosts exposing an IPv6 address are also running DHCPv6, we found out that 66,471 of the 1,155,555 hosts (obtained via Shodan search) were also exposing an IPv6 address.
Requirements for exploiting CVE-2017-14495 and 14496
To exploit these vulnerabilities, the attacker must be able to send network packets to the DNS or DHCP subsystems of the target host running Dnsmasq. More specifically, like CVE-2017-14491, Dnsmasq is exploitable via CVE-2017-14494 only if DHCPv6 is enabled.
For both CVE-2017-14495 and 14496, Dnsmasq is exploitable only if run with any of the following options, which are all used to append additional fields to the outgoing, forwarded DNS queries. The first two are part of the Extension Mechanisms for DNS (or EDNS0, RFC2671):
- --add-mac appends the requestor's MAC address to each outgoing DNS query. In the manual page, the developer cautiously warns that it's a non-standard feature and still experimental. Interestingly, in 2011, a user might have unknowingly triggered the very same bug on a similar feature that the developer described as "not likely to be well-used and therefore well-tested."
- --add-cpe-id appends an arbitrary string (supplied by the user while defining the option) to each outgoing DNS query.
- --add-subnet changes the subnet address appended to each outgoing DNS query (normally, this field is filled with the requestor's address).
How do I check if my devices are affected?Quoting Google Security's blog post:
Android partners have received this patch as well and it will be included in Android's monthly security update for October. Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod. Other affected Google services have been updated.
What about other settings? Although going through the requirements mentioned in the previous paragraphs should suffice as a first assessment, the flowchart at the beginning of this post can serve as a slightly more "operational" workflow for end users.
How do I secure my devices?The above flowchart illustrates some of the suggested remediation actions that you can take. Let's quickly go through them.
- If your distribution already offers a packaged upgrade to Dnsmasq 2.78, follow the distribution-specific instructions to upgrade the package.
- Those without a packaged upgrade will have to build Dnsmasq from source code (either from the 2.78 release or the official Git repository).
- The worst case scenario is if you're running a customized version of Dnsmasq because you will need to adopt a patch to fit the customized source code.
Regardless of whether you can apply any of the above-suggested fixes, it's recommended that you follow generic network-security best practices, especially if your only option is to run a vulnerable version of Dnsmasq. To reduce the chances of successful exploitation, we recommend the following:
- Turn off the affected Dnsmasq options (see the table above) if not being used.
- Whitelist the hosts that can interact with the Dnsmasq service to limit the (untrusted) actors that can send network packets to the target device.
- Use a trusted upstream DNS server. In SOHO settings, the upstream DNS servers are typically dynamically assigned by the ISP, so they’re trusted as long as you trust your ISP. However, if an attacker manages to get between your Dnsmasq installation (e.g., running in your router) and the benign, ISP-assigned upstream DNS server, the attacker could intercept the upstream queries and deliver a CVE-2017-14491 exploit in the responses.
- In case you're running Dnsmasq in a router, we suggest that you review the remediation steps suggested in our article on (home) routers security.
- If none of these steps apply, you should focus on detecting attempts to exploit these vulnerabilities, which usually means that you have to have proper IPS signatures in place.
Trend Micro SolutionsTo protect users from IoT malware and similar threats, the Trend Micro™ Smart Home Network* solution features web protection and deep packet inspection capabilities that is capable of detecting attempts to exploit these vulnerabilities.
TippingPoint customers are protected via the following filters:
- 29729: DNS: Dnsmasq DNS Response Buffer Overflow Vulnerability
- 29730: DNS: Dnsmasq DNS Inverted Query Denial-of-Service Vulnerability
- 29731: DNS: Dnsmasq DNS add_pseudoheader Denial-of-Service Vulnerability
- 29732: ICMP: Dnsmasq ICMPv6 Router Advertisement Buffer Overflow Vulnerability
- 29733: DHCP: Dnsmasq DHCPv6 Relay-Forward Buffer Overflow Vulnerability
- 29734: DHCP: Dnsmasq DHCPv6 Relay-Forward Information Disclosure Vulnerability
Deep Discovery Inspector protects customers via these DDI rules:
- Beta Rule ID 3751:CVE-2017-14491 DNSMASQ Buffer Overflow Exploit - DNS(Response)
- Beta Rule ID 3752: CVE-2017-14493 DNSMASQ Buffer Overflow Exploit - DHCP(Request)
- Official Rule ID 2517, Beta Rule ID 3753: CVE 2017-14496 DNSMASQ Integer Underflow Exploit - DNS(Request)