Original date: 11.12.2018
Overall risk classification: HIGH
This vulnerability opens the possibility to create a connection through the Kubernetes API server to a backend server. This connection can be used to send arbitrary requests to the backend server. The connection and requests are authenticated with the TLS credentials of the Kubernetes API servers. Depending on the configurations, this could potentially be exploited to run arbitrary code. [1]
Two days ago, a PoC exploit for this vulnerability was published [2].
Whether your Kubernetes is vulnerable or not also depends on some configurations:
For Clusters >= 1.6.x that run aggregated API servers that are directly accessible from the Kubernetes API server’s network.
For Clusters >= 1.0.x that grad pod exec/attach/portforward permissions.
More details at [1].
Risk: HIGH
Two possible impacts of this vulnerability were described:
API calls to aggregated API server endpoints can be escalated to perform any API request against that aggregated API server. When using the default RBAC policy, this can be performed by authenticated and unauthenticated users.
A pod exec/attach/portforward API call can be escalated to perform any API request against the kubelet API on the node specified in the pod spec. This could lead to information disclosure or remote-code-execution.
Exploitability: HIGH
The exploitation against the aggregated API server requires that the aggregated API server is directly accessible from the Kubernetes API server’s network.
For the exploitation of the pod exec/attach/portforward API calls a PoC exploit have been published [2].
Priority (for affected, internet-exposed systems): HIGH
Priority (for internal systems): MEDIUM
Upgrade Kubernetes or check whether the mitigation steps described in [1] can be applied to avoid the upgrade.
Martin Schöne
[1] https://github.com/kubernetes/kubernetes/issues/71411
[2] https://github.com/evict/poc_CVE-2018-1002105