dnsmsq software version 2.78 download How to compile dnsmasq 2.78? I wanted to compile the new dnsmasq from thekelleys.org. This worked, but then I realized that the flags are not the same as in the original ubuntu- version 2.76-5: So I changed the config.h but got some errors which I don't know to resolve: #define HAVE_IDN: idna.h not found. Where is libnetfilter_conntrack.h and how to include rsa.h? Where can I find the config.h for the current ubuntu version which has already been modified by canonical? 1 Answer 1. If you want to compile dnsmasq on your own you should install development headers for the libraries it links to, plus gettext for the internationalization (i18n). On ubuntu, it would be these packages: gettext libdbus-1-dev libidn11-dev libnetfilter-conntrack-dev nettle-dev. In general, you have a file name such as libnetfilter_conntrack.h and you want to know which package provides that file you can use the web site https://packages.ubuntu.com/ and then use 'search for the contents of packages', it will take you to https://packages.ubuntu.com/search? searchon=contents&keywords=libnetfilter_conntrack.h&mode=exactfilename&suite=bionic&arch=any and tell you the package you search for is called libnetfilter-conntrack-dev . So now, if you modify dnsmasq s src/config.h like this: and you use make all-i18n as the make target, you'll get a binary with the same options as stock ubuntu: And if you want to find out which options or even patches Ubuntu exactly used to compile their binary package, you can use apt-get source dnsmasq to get the sources for the package with the same name. Google Warns of DoS and RCE Bugs in Dnsmasq. A domain name system server implementation is at risk of remote code execution, information exposure and denial-of-service attacks after a seven vulnerability were disclosed by Google and patched by the maintainers of Dnsmasq. Seven flaws in what is known as Dnsmasq can be exploited by attackers who can use the bugs to carry out remote code execution, information exposure or a denial of service attacks against affected devices. Google researchers identified the flaws in a research paper published Monday, the same day a patch for affected hardware arrived. Google also published proof-of-concept code to demonstrate the flaws and is urging hardware vendors to deploy patches as soon as possible. Dnsmasq is open-source software that can be found in Android OS and Mac OS X. It’s also included in popular desktop Linux distributions including FreeBSD, OpenBSD and NetBSD, and in home routers, IoT devices and for tethering of smartphones and portable hotspots, said Google. “During our review, 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,” wrote researchers behind the Google Security Blog. The Dnsmasq software package acts as a local domain name system (DNS) helping devices identify other devices and route traffic within small networks. “(Dnsmasq) is designed to be lightweight and have a small footprint, suitable for resource constrained routers and firewalls,” the maintainer of Dnsmasq, Simon Kelley, said. On Monday, Kelley announced a fix for the vulnerability that includes upgrading to Dnsmasq version 2.78. All versions of Dnsmasq 2.77 and prior contain the multiple vulnerabilities. “I’ve just released dnsmasq-2.78, which addresses a series of serious security vulnerabilities,” Kelley said. “Some of these, including the most serious, have been in Dnsmasq since prehistoric times, and have remained undetected through multiple previous security audits.” According to Google, its Android partners have or will receive a patch as part of the October Android security update released Wednesday. Google said the Dnsmasq vulnerabilities can be triggered remotely via DNS and dynamic host configuration protocol (DHCP) that could lead to the remote code execution, information exposure and denial of service conditions. DNS attacks can be problematic for companies ill equipped to mitigate against them, a survey of firms said last month. “Despite heightened DDoS attacks, many companies have inadequate defenses when it comes to DNS security,” the study, carried out by security firm Infoblox said.. The study found one-third of “professionals” surveyed doubt their company can defend against a DNS attack. In the case of Dnsmasq, the three remote code execution vulnerabilities (CVE-2017-14491, CVE-2017-14492 and CVE-2017-14493) are tied to heap buffer overflow and stack buffer overflow errors through DHCP and DNS. Another three vulnerabilities (CVE-2017-14495, CVE-2017-14496 and CVE-2017-13704) are denial of service bugs caused by invalid boundary checks, bug collisions and memory leakage. The bug for the information leak (CVE-2017-14494) can be exploited to bypass the address space layout randomization (ASLR) memory protection function and allows remote attackers to obtain sensitive memory information via vectors involving handling DHCPv6 forwarded requests, according to the Common Vulnerabilities and Exposures (CVE) description. Dnsmsq software version 2.78 download. Zyxel is aware of the recently disclosed vulnerabilities of dnsmasq, as identified in US-CERT vulnerability note VU#973527 with vulnerability IDs CVE-2017-14491 through CVE-2017-14496 and CVE-2017-13704, as listed in table 1. What are the vulnerabilities? Dnsmasq is a piece of open-source software widely used in Android, Linux and a variety of networking equipment operating systems. The vulnerabilities are present in dnsmasq version 2.77 and earlier; version 2.78 of dnsmasq has been released to address these vulnerabilities. Table 1. CVE Issue Vector CVE-2017-14491 Heap-based Buffer Overflow DNS CVE-2017-14492 Heap-based Buffer Overflow DHCP CVE-2017- 14493 Stack-based Buffer Overflow DHCP CVE-2017-14494 Information Exposure DHCP CVE-2017-14495 Uncontrolled Resource Consumption (resource exhaustion) DNS CVE-2017-14496 Integer Underflow DNS CVE-2017-13704 Integer Underflow DNS. How are Zyxel resolving the vulnerabilities? At Zyxel we treat security as a top priority and we have conducted a thorough investigation and identified a list of vulnerable products within their warranty and support period, as shown in table 2 below. For products not listed, they are not affected because they do not make use of dnsmasq. We are now deploying or backporting the latest version of dnsmasq (version 2.78) into the vulnerable products. Please refer to table 2 for the detailed release schedule. Please contact your local Zyxel support team to get the patch firmware file. Table 2. Product Series/Model Patch firmware version Availability DSL CPE AMG1302-T11C ABCG12C0 Feb 2018 VMG1312-B10A AAJZ14C0 Jan 2018 VMG1312-B10D V5.13(AAXA.7) Dec 2017 VMG1312-B30A AATO9C0 Jan 2018 VMG3312-T series ABFX1C0 Dec 2017 VMG3625-T series ABIE1C0 Oct 2017 VMG3925-B10B AAVF10C0 Dec 2017 VMG3926-B10A AAVF10C0 Dec 2017 VMG5313- B10B V5.13(AAYY.6) Dec 2017 VMG8823-B10B V5.13(ABEJ.2) Dec 2017 VMG8823-B30B V5.13(ABEJ.2) Dec 2017 VMG8823- B50B V5.13(ABEJ.2) Dec 2017 VMG8823-B60B V5.13(ABEJ.2) Dec 2017 VMG8924-B10A VMG8324-B10A AAKL20C0 Jan 2018 VMG8924-B10D V5.13(ABGQ.1) Dec 2017 VMG8924-B30A AAPQ14C0 Jan 2018 VMG8924-B30D V5.13(ABGP.1) Jan 2018 XMG3512-B series ABDR1C0 Mar 2018 DSL CPE (Gemini) Gateway 400 6.38.2.10.03 13-Oct 2017 Speedlink 5501/6501 4.38.2.10.06 13-Oct 2017 Speedlink 5502 7.39.2.01.00 27-Oct 2017 VMG5304 8.39.3 27-Oct 2017 VMG8029 10.39.3 20-Oct 2017 VMG8546 9.39.3 20-Oct 2017 Ethernet gateway EMG2306 V1.00(AAJM.5)C0 Dec 2017 EMG2926 V1.00(AAVK.6)C0 Oct 2017 EMG3425 V1.00(AAYJ.11)C0 Dec 2017 GPON ONT PMG5317-T20A V521ABCI4C0 30-Nov 2017 PMG5317-T20B V540ABKI1C0 30-Nov 2017 Home router NBG6515 V1.00(AXS.5)C0 Feb 2018 NBG6604 V1.00(ABIR.2)C0 Feb 2018 NBG6617 V1.00(ABCT.6)C0 Feb 2018 NBG6815 V1.00(ABBP.7)C0 Apr 2018 NBG6816 V1.00(AAWB.10)C0 Dec 2017 NBG6817 V1.00(ABCS.8)C0 Apr 2018 LTE CPE LTE4506-M606 V1.00(ABDO.3)C0 15-Dec 2017 LTE7410 V2.60(ABAW.6)C0 Feb 2018 LTE7460 V1.00(ABFR.4)C0 20-Dec 2017 WAH7706 V1.00(ABBC.8)C0 22-Dec 2017 WiFi system WSQ50 V1.00(ABKJ.2)C0 10-Nov 2017 Wireless extender WAP6806 V1.00(ABAL.6)C0 18-Feb 2018. What should I do now to protect against the vulnerabilities? The following short-term mitigations could be put in place to remove or reduce the threat: For ISP customers, ISP’s DNS server filters all DNS responses to check for the malicious code Zyxel CPE is reconfigured so that it does not act as the DNS server for LAN side DHCP clients by issuing the DNS servers as “obtained from ISP” or DNS static IPs. Note this mitigation is only applicable to VDSL and LTE models. For more information and technical details regarding the vulnerabilities please see below references: A Set of Severe Flaws Affect Popular DNSMasq DNS Forwarder. Cybersecurity researchers have uncovered multiple vulnerabilities in Dnsmasq, a popular open-source software used for caching Domain Name System (DNS) responses, thereby potentially allowing an adversary to mount DNS cache poisoning attacks and remotely execute malicious code. The seven flaws, collectively called " DNSpooq " by Israeli research firm JSOF, echoes previously disclosed weaknesses in the DNS architecture, making Dnsmasq servers powerless against a range of attacks. "We found that Dnsmasq is vulnerable to DNS cache poisoning attack by an off-path attacker (i.e., an attacker that does not observe the communication between the DNS forwarder and the DNS server)," the researchers noted in a report published today. "Our attack allows for poisoning of multiple domain names at once, and is a result of several vulnerabilities found. The attack can be completed successfully under seconds or few minutes, and have no special requirements. We also found that many instances of Dnsmasq are misconfigured to listen on the WAN interface, making the attack possible directly from the Internet." Dnsmasq, short for DNS masquerade, is a lightweight software with DNS forwarding capabilities used for locally caching DNS records, thus reducing the load on upstream nameservers and improving performance. As of September 2020, there were about 1 million vulnerable Dnsmasq instances, JSOF found, with the software included in Android smartphones and millions of routers and other networking devices from Cisco, Aruba, Technicolor, Redhat, Siemens, Ubiquiti, and Comcast. Revisiting Kaminsky Attack and SAD DNS. The concept of DNS cache poisoning is not new. In 2008, security researcher Dan Kaminsky presented his findings of a widespread and critical DNS vulnerability that allowed attackers to launch cache poisoning attacks against most nameservers. It exploited a fundamental design flaw in DNS — there can be only 65,536 possible transaction IDs (TXIDs) — to flood the DNS server with forged responses, which is then cached and leveraged to route users to fraudulent websites. The transaction IDs were introduced as a mechanism to thwart the possibility that an authoritative nameserver could be impersonated to craft malicious responses. With this new setup, DNS resolvers attached a 16-bit ID to their requests to the nameservers, which would then send back a response with the same ID. But the limitation in transaction IDs meant that whenever a recursive resolver queries the authoritative nameserver for a given domain (e.g., www.google.com), an attacker could flood the resolver with DNS responses for some or all of the 65 thousand or so possible transaction IDs. If the malicious answer with the right transaction ID from the attacker arrives before the response from the authoritative server, then the DNS cache would be effectively poisoned, returning the attacker's chosen IP address instead of the legitimate address for as long as the DNS response was valid. The attack banked on the fact that the entire lookup process is unauthenticated, meaning there is no way to verify the identity of the authoritative server, and that DNS requests and responses use UDP (User Datagram Protocol) instead of TCP, thereby making it easy to spoof the replies. To counter the problem, a randomized UDP port was used as a second identifier along with the transaction ID, as opposed to just using port 53 for DNS lookups and responses, thus raising the entropy in the order of billions and making it practically infeasible for attackers to guess the correct combination of the source port and the transaction ID. Although the effectiveness of cache poisoning attacks has taken a hit due to the aforementioned source port randomization (SPR) and protocols such as DNSSEC (Domain Name System Security Extensions), researchers last November found a "novel" side-channel to defeat the randomization by using ICMP rate limits as a side-channel to reveal whether a given port is open or not. The attacks — named "SAD DNS" or Side-channel AttackeD DNS — involves sending a burst of spoofed UDP packets to a DNS resolver, each sent over a different port, and subsequently using ICMP "Port Unreachable" messages (or lack thereof) as an indicator to discern if the rate limit has been met and eventually narrow down the exact source port from which the request originated. Mount Multi-Staged Attacks That Allow Device Takeover. Interestingly, the DNS cache poisoning attacks detailed by JSOF bear similarities to SAD DNS in that the three vulnerabilities (CVE-2020- 25684, CVE-2020-25685, and CVE-2020-25686) aim to reduce the entropy of the Transaction IDs and source port that are required for a response to be accepted. Specifically, the researchers noted that despite Dnsmasq's support for SPR, it "multiplexes multiple TXIDs on top of one port and does not link each port to specifics TXIDs," and that the CRC32 algorithm used for preventing DNS spoofing can be trivially defeated, leading to a scenario where "the attacker needs to get any one of the ports right and any one of the TXIDs right." Dnsmasq versions 2.78 to 2.82 were all found to be affected by the three flaws. The other four vulnerabilities disclosed by JSOF are heap-based buffer overflows, which can lead to potential remote code execution on the vulnerable device. "These vulnerabilities, in and of themselves, would have limited risk, but become especially powerful since they can be combined with the cache- poisoning vulnerabilities to produce a potent attack, allowing for remote code execution," the researchers said. Even worse, these weaknesses can be chained with other network attacks such as SAD DNS and NAT Slipstreaming to mount multi-staged attacks against Dnsmasq resolvers listening on port 53. Even those that are configured to only listen to connections received from within an internal network are at risk if the malicious code gets transmitted via web browsers or other infected devices on the same network. Besides rendering them susceptible to cache poisoning, the attacks can also permit a bad actor to take control over routers and networking equipment, stage distributed denial-of-service (DDoS) attacks by subverting traffic to a malicious domain, and even prevent users from accessing legitimate sites (reverse DDoS). The researchers also raised the possibility of a "wormable attack" wherein mobile devices connected to a network that uses an infected Dnsmasq server receives a bad DNS record and is then used to infect a new network upon connecting to it. Update Dnsmasq to 2.83. It's highly recommended that vendors update their Dnsmasq software to the latest version (2.83 or above) that will be released later today in order to mitigate the risk. As workarounds, researchers suggest lowering the maximum queries allowed to be forwarded, as well as rely on DNS-over-HTTPS (DoH) or DNS-over-TLS (DoT) to connect to the upstream server. "DNS is an Internet-critical protocol whose security greatly affect[s] the security of Internet users," the researchers concluded. "These issues put networking devices at risk of compromise and affect millions of Internet users, which can suffer from the cache poisoning attack presented. "This highlight[s] the importance of DNS security in general and the security of DNS forwarders in particular. It also highlights the need to expedite the deployment of DNS security measures such as DNSSEC, DNS transport security, and DNS cookies." Security Alert: Patch Dnsmasq on Your Linux Servers, Kubernetes and Networking Devices. Security researchers from Google have recently found serious vulnerabilities in dnsmasq, a software package used in Linux, BSD and macOS to set up Domain Name Server (DNS) and Dynamic Host Configuration Protocol (DHCP) services for networks. Dnsmasq is also used in Kubernetes, which included a patched DNS pod in versions 1.5.8, 1.6.11, 1.7.7 and 1.8.0. Kubernetes 1.8 was released on Sept. 28 and also has some other security enhancements. With its small footprint, dnsmasq is also widely used in routers and other networking equipment, as well as is firewalls and mobile device hotspots. The Google researchers found three remote code execution flaws, three denial-of-service issues and an information leak bug that could help attackers bypass the Address Space Layout Randomization (ASLR) anti-exploitation mechanism. They worked with dnsmasq maintainer Simon Kelley and the flaws were fixed in dnsmasq version 2.78. If dnsmasq is configured to provide external DNS or DHCP services, these vulnerabilities can potentially be exploited from the internet. Linux servers administrators should make sure they obtain the updated dnsmasq packages from distribution maintainers. However, the software is also present in a variety of Linux-based embedded networking devices, including routers, and those devices will require updates from their respective vendors. One of the remote code execution vulnerabilities, tracked as CVE-2017-14491, can be exploited over DNS, and the other two, CVE-2017- 14492 and CVE-2017-14493, can be exploited over DHCP. If dnsmasq is configured to provide external DNS or DHCP services, these vulnerabilities can potentially be exploited from the internet. Researchers from security firm Trend Micro identified around 1 million devices that are running a vulnerable version of dnsmasq and expose a DNS service (port 53) on the public internet. In addition to working with Kelley to fix the flaws, the Google researchers also contributed a patch to the project that aims to harden dnsmasq against exploits in the future. The patch still needs to be reviewed and integrated into the software, but its goal is to run dnsmasq under the Linux kernel’s seccomp-bpf sandboxing mechanism.Sandboxing makes it harder for what attackers could do if they exploit a remote code execution flaw in the software in the future. Sandboxing makes it significantly harder for attackers to exploit vulnerabilities in order to achieve arbitrary code execution with kernel privileges because the targeted process is isolated by an additional layer that would require a separate vulnerability and exploit to defeat. Until Google’s patch is accepted and integrated into dnsmasq, users can download and apply it manually to their installations. Of course, thorough testing should be performed before deploying the patch on production systems. Users are advised to upgrade their systems as soon as possible because proof-of-concept exploits for the flaws are available and hackers could use them to develop malicious attacks. As far as Kubernetes version 1.8 goes, the role-based access control (RBAC) feature has reached stable status and the new release also comes with beta support for filtering outbound traffic through network policies. In addition, the Kubelet node agent now has beta support for Transport Layer Security (TLS) certificate rotation, which is expected to simplify secure cluster operation.