Google recently announced that they have discovered seven new vulnerabilities in the Domain Name System software package Dnsmasq, which provides DNS name resolution services to translate domain names to their corresponding IP addresses for connectivity purposes.

A post on the company’s security blog said that the team “found three potential remote code executions, one information leak, and three denial of service vulnerabilities affecting the latest version at the project git server as of September 5th 2017.” In other words, the exploit could gain administrative privileges on a device, provide access to confidential information or adversely impact device operation.

The exploit cannot be triggered via unsolicited inbound traffic.To leverage the vulnerability, an attacker would need to have administrative access to a malicious domain such as The attacker could then lure users to try to access which would rely upon DNS requests by the dnsmasq module. These requests would involve cached replies from By constructing or arranging specific DNS requests and responses, an attacker could trigger an internal buffer overflow via dnsmasq which could execute code they have provided.

Dnsmasq also features DHCP services as well as network functions such as router advertising and network boot. It is commonly used and operates upon an array of operating systems and devices; Red Hat Enterprise Linux, Ubuntu, Debian, CentOS, Slackware, Android, FreeBSD, OpenBSD, NetBSD, macOS, and various home routers and IoT devices.

Red Hat confirmed that a critical Dnsmasq heap buffer overflow vulnerability (CVE-2017-14491) considered to be “the worst vulnerability” has the potential to affect all versions of Dnsmasq in their products.

SEE: Network security policy (Tech Pro Research)

While this is a fairly typical set of vulnerabilities for operating systems, the Dnsmasq issue has the potential to loom large in the IoT realm. Shodan, a search engine for IoT-related devices, reports that at present over 1.2 million devices can potentially be impacted.

Craig Young, computer security researcher for Tripwire‘s Vulnerability and Exposures Research Team, said that the vulnerabilities will have minimal impact against Android due to existing security mechanisms, but they may cause much more trouble for IoT everywhere. “The CVE-2017-14491 bug is classified as being an RCE bug exploitable through crafted DNS replies. Fortunately, there are many factors making it unlikely that attackers will incorporate exploits for this vulnerability into something like Mirai (Malware which can turn networked devices using Linux into remote-controlled bots which can launch attacks on systems and networks),” he wrote.

Young stated that the most likely attack scenario he could envision would be an attack campaign utilizing crafted web pages, IMs, and emails intended to trigger outbound DNS requests to a server in the attacker’s control.

“While some on the Internet have claimed that this vulnerability can only be exploited by a PTR (reverse DNS) record query, my assessment is that a crafted response to a canonical name record (CNAME or alias) can trigger the vulnerability making this attack possible,” he said.

Even in this scenario however, Young said it is unlikely that an exploit could be crafted to reliably get code execution on the wide range of vulnerable devices all potentially running different OS versions with different libraries and variations of dnsmasq. Nevertheless, he stated it is still a critical imperative for IoT vendors to address the topic and develop updates for affected products since the possibility of widespread attack cannot be entirely ruled out.

SEE: Defending against cyberwar: How the cybersecurity elite are working to prevent a digital apocalypse (free PDF) (TechRepublic)

What do you need to do?

As a system administrator, I agree with Young: regardless of threat level or severity, vulnerabilities should always be patched since it makes for best practices and often security or governance requirements leave you no choice.

For Red Hat operating systems, run yum update -y to patch all existing implementations of Dnsmasq. Ubuntu users should utilize the “sudo apt-get upgrade” command to apply all available updates. Update mechanisms may vary for FreeBSD, OpenBSD and NetBSD, but the “pkg_add -ui” command should work for all of them. Mac OS users can use the App Store to apply available updates.

You can also find the latest dnsmasq package here for manual installation; 2.78 is the approved version.

For Android products, the October Android security update will contain a fix for these issues so make sure to update devices or instruct your user base to do so as soon as a software update is available.

For routers and IoT devices, contact your vendor or visit their website to determine if their products are affected and if so whether a patch is available and how to apply it. Generally this will be in the form of a firmware update which you can use to “flash” the device. Prioritize your schedule so that internet-connected devices are updated first, followed by those operating exclusively on local networks.

Also consider using firewall rules to segregate traffic from unwanted subnets or block internet access entirely on servers (it’s been years since I’ve accessed the internet from any server other than a test system). Manufacturers generally have a “turn everything on for user convenience, to reduce support calls and promote device usage” mindset, so turning off unnecessary functions or services is also always a good idea, regardless of the operating system or device involved.

Also see: