Portmap: append, rather than prepend, entry rules - CVE-2019-9946

[squeed]

This means that portmapped connections can be more easily controlled / firewalled.

[matthewdupre]

I'll try this out with Calico

[bboreham]

LGTM

[dcbw]

/lgtm

[matthewdupre]

(Seems to work with Calico)

[philips]

This issue was coordinated with the CNI team as it caused a potential security issue with Kubernetes.

See the details below.

A security issue was discovered with interactions between the CNI (Container Networking Interface) portmap plugin versions prior to 0.7.5 and Kubernetes. The CNI portmap plugin is embedded into Kubernetes releases so new releases of Kubernetes are required to fix this issue. The issue is Medium and upgrading to Kubernetes 1.11.9, 1.12.7, 1.13.5, and 1.14.0 is encouraged to fix this issue if this plugin is used in your environment.

Am I vulnerable?

As this affects a Kubernetes plugin interface it is difficult to say with certainty without a complete understanding of your Kubernetes configuration. The issue was identified in a configuration of kube-proxy in IPVS mode along with a pod using a HostPort. However, other network configurations may use the CNI portmap plugin as well.

Run kubectl version --short | grep Server and if it does not say 1.11.9, 1.12.7, 1.13.5, and 1.14.0 or newer you are running a vulnerable version if paired with a CNI configuration that uses the portmap plugin.

How do I upgrade?

Follow your management tool or vendor instructions to upgrade to the latest release of Kubernetes.

Vulnerability Details

Before this fix the 'portmap' plugin, used to setup HostPorts for CNI, would insert rules at the front of the iptables nat chains; which would take precedence over the KUBE- SERVICES chain. Because of this, the HostPort/portmap rule could match incoming traffic even if there were better fitting, more specific service definition rules like NodePorts later in the chain.

Switching the portmap plugin to append its rules, rather than prepend, allows traffic to be processed by KUBE-SERVICES rules first. Only if traffic does not match a service will it be considered for HostPorts. This is compatible with the behavior of the legacy ‘kubenet’ network driver.

See the GitHub issue for details. kubernetes/kubernetes#75455 and #269

Thank you

Thank you to Etienne Champetier of Anevia for identifying the issue, Tim Hockin, Dan Williams, Casey Callendrello, Dujun, Tim Pepper, and the patch release managers for the coordination is making this release.

Thank You,

Brandon on behalf of the Kubernetes Product Security Committee

[thockin]

I have identified 2 specific variants of this CVE, all covered by the same fix.

1. As before, you need a pod with a hostPort and a service using the same port number. In this case the service has to be type=LoadBalancer
   and your LB implementation has to assign LB IPs to local interfaces on nodes. In that case, the LB IP is considered "local" and will match the hostPort before matching the service.

2. If you have a service of type NodePort or LoadBalancer, and I can learn the exact nodePort number for your Service, I can craft a pod using that as a hostPort, which will match before the service. This includes any load-balancer or ingress which uses the nodePort to route traffic.