This article is more than 1 year old

Dnsmasq, used in only a million or more internet-facing devices globally, patches not-so-secret seven spoofing, hijacking flaws

Get your updates when you can for gear from scores of manufacturers

Seven vulnerabilities have been found in a popular DNS caching proxy and DHCP server known as dnsmasq, raising the possibility of widespread online attacks on networking devices.

The flaws, collectively dubbed DNSpooq, were revealed on Tuesday by Israel-based security firm JSOF at the conclusion of a five-month coordinated disclosure period. The bugs are believed to affect products from more than 40 IT vendors, including Cisco, Comcast, Google, Netgear, Red Hat, and Ubiquiti, and major Linux distributions.

JSOF researchers identified three cache poisoning bugs (CVE-2020-25686, CVE-2020-25684, CVE-2020-25685) and four buffer overflow bugs (CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681).

Dnsmasq 2.83, maintained by open source software developer Simon Kelley, has been released to address the issues, which recall the DNS cache poisoning vulnerability identified in 2008 by security researcher Dan Kaminsky.

That 2008 bug allowed an attacker to inject data into a recursive nameserver’s cache, in order to send web users to a malicious website via bogus DNS responses. And DNSpooq is similar: it allows fake DNS records to be added to the dnsmasq cache, potentially for long periods of time, among other plausible ills. That means victims could end up connecting to what they think is a legit website or service, but in fact they're connecting to a malicious machine masquerading as the other site, which could harvest credentials and other sensitive information. There are defenses for these kinds of DNS spoofing attacks, such as using HTTPS and SSH.

"There are broadly two sets of problems," wrote Kelly in an email sent to the dnsmasq mailing list. "The first is subtle errors in dnsmasq's protections against the chronic weakness of the DNS protocol to cache-poisoning attacks; the Birthday attack, Kaminsky, etc. The code is now as secure as it can be, given that the real solution to this is DNSSEC, both endpoint validation and domains actually signing.


Two clichés, one headline: 'No good deed goes unpunished' and 'It's always DNS'


"Unfortunately, given the above, the second set of errors is a good old fashioned buffer overflow in dnsmasq's DNSSEC code. If DNSSEC validation is enabled, an installation is at risk."

The three cache poisoning flaws work by reducing the entropy (randomness) of the TXID (Transaction ID) in the DNS header and source port. If the attacker can guess the TXID and source port, the server will allow the attacker to alter the cache, and potentially redirect victims to malicious servers. The high-severity buffer overflow could enable remote code execution when dnsmasq has been configured to use DNSSEC, and the lower-severity overflows could be used for denial of service when DNSSEC is in place.

"One of the interesting things about these vulnerabilities is that each one of them, on its own, has limited impact," explained JSOF in its writeup.

"However, the vulnerabilities could be combined and chained in certain ways to build extremely effective multi-staged attacks. This is because exploiting some of the vulnerabilities makes it easier to exploit others."

According to JSOF, there are around one million dnsmasq servers visible on the public internet, and in addition to the risk of cache poisoning, at least one of the vulnerabilities could be used for remote code execution to hijack home routers and other networking gear. The bugs could also be used to create wormable and DDoS attacks.

Threat scenarios include targeting dnsmasq resolvers listening to port 53 through the internet-accessible WAN interface or, via an attacker-controlled machine on a local area network. Or an attacker with a server on the internet could affect a machine on a LAN that browses a website with attacker-controlled JavaScript in Safari or Chrome.

JSOF said that since the disclosure is being coordinated through CERT/CC, its researchers aren't sure how or when affected vendors will respond. They expect the major operating system distributors and vendors like Red Hat and Ubuntu will issue patches, followed by updates issued by other vendors. ®

More about


Send us news

Other stories you might like