Background

This week a Google research team disclosed findings of multiple Dnsmasq vulnerabilitiesTheir findings gained a lot of traction online, with good reason. Dnsmasq is a DNS forwarder and cache server and also a DHCP server, with some other features too. It is a popular tool and it has been embedded inside various projects.

The findings were relevant to our team at Twistlock because Kubernetes was listed among affected projects. The Kubernetes DNS pod relies on dnsmasq, and it is likely directly vulnerable to attacks using the mentioned vulnerabilities. The Google researchers mentioned Kubernetes versions 1.5.8, 1.6.11, 1.7.7 and 1.8.0 had already been updated with a patched DNS pod.

Kubernetes can be installed by several ways, in all of them (either kubeadm, minikube or as part of Openshift) you will get a listening dnsmasq service. On kubeadm and minikube deployments dnsmasq runs inside a container and is accessible only through the container network, which limits the scope of exploitation.

On Openshift the issue is more severe, dnsmasq binds on all the interfaces of the host. Hosts connected directly to the internet without NAT or load balancer are exposed. We recommend that users promptly update Kubernetes to fix these vulnerabilities.. Dnsmasq can be sandboxed with SECCOMP, but this fix will only offer a temporary patch and will not provide full protection against sophisticated exploits.

Dnsmasq Vulnerability Details

Instead of explaining each flaw in detail, the researchers put out a PoC (proof-of-concept) exploit for each of the vulnerabilities they found. Readers that are used to detailed posts (like in Google’s Project Zero) would be disappointed to find they have to read the crash reports or the fix commits, and figure out the bugs by themselves. Nevertheless, let’s examine the descriptions of the vulnerabilities:

  • CVE-2017-14491 is a heap overflow vulnerability. It’s triggered through a DNS request. According to the researchers, before dnsmasq 2.76 the overflow length was unlimited, and with later versions it is only possible to overflow 2 bytes. The researchers have managed achieve RCE (remote code execution) using this vulnerability.
  • CVE-2017-14492 and CVE-2017-14493 are two memory overflows triggered through the DHCP server. The first is a heap based overflow and the second a stack overflow. From examining the PoC instructions they both seem to rely on IPv6. The researchers mentioned they reached RCE for both vulnerabilities.
  • CVE-2017-14494 is an information leak vulnerability within the DHCP server. It can be used to bypass ASLR when writing an exploit for the previous ones.
  • CVE-2017-14495, CVE-2017-14496 and CVE-2017-13704 are bugs in the DNS server that results in DoS. The first, by allocating memory and not freeing it, the second by an integer overflow resulting in a huge memcpy, and the last one is crashing upon receiving a large UDP packet.

Conclusion

Finally, if you want to reproduce the PoCs by yourself, you would have to use a vulnerable version of dnsqmasq, as the the latest ones are patched. See their PoC project and a small diff I made to reproduce the exploits, using the same environment and Dockerfile the researchers provided. Their instructions are somewhat vague in most parts, but this may be deliberate.

At Twistlock Labs, we want to ensure that customers using container platforms and orchestrators, especially Kubernetes, are always protected from vulnerable components in their environments. We hope this post illustrates how we evaluate relevant security research in order to continuously improve the Twistlock Platform. Follow us on Twitter for regular research alerts and updates!

What’s Next:

← Back to All Posts Next Post →