5 ms·
This affects all versions of Kubernetes between 1.5.0 and 1.7.6. Relevant posts: - https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzhD3JhhE https://
by philips 9y ago
This affects all versions of Kubernetes between 1.5.0 and 1.7.6.
Relevant posts:
- https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzhD3JhhE https://groups.google.com/forum/#!topic/kubernetes-dev/QWIzh...
- https://coreos.com/blog/dns-vulnerability-patched-in-kubernetes-and-tectonic https://coreos.com/blog/dns-vulnerability-patched-in-kuberne...
- thesandlord 9y ago> Kubernetes versions 1.5.8, 1.6.11, 1.7.7, and 1.8.0 have been released with a patched DNS pod.
- theptip 9y agoPer the kubernetes-dev post, all affected GKE clusters have been patched for you: > All GKE clusters have already been patched, so no action is necessary for GKE users. Users will see a "-gke.1" version for the MASTER_VERSION of their GKE clusters, which contains the patch.
- bboreham 9y agoI'm wondering how exploitable this is. Kube-dns doesn't listen outside of the cluster, so to you need to be able to run arbitrary code inside the cluster to make use of it. Then it lets you escape to the dnsmasq container. Which does have a shell, but I'm struggling to think how this gets you more capability than "able to run arbitrary code inside the cluster". Most likely I missed something. Help me spot it.
- dward 9y agoIt is far harder to exploit on Kubernetes then on a laptop running a dnsmasq cache attached to a starbucks wifi. You would need to middle man traffic between dnsmasq and upstream DNS or have some control over DNS records and be able to force dnsmasq to do lookups. As you point out the escalation is also far more limited. Ok, so you have a shell in the dnsmasq container. Now what?