Rory Mccune

A security issue in the Kubelet and kube-proxy components allows adjacent hosts to reach TCP and UDP services bound to 127.0.0.1 running on the node or in the node's network namespace. This means that services thought to be reachable only by other processes on the same host could be accessed by other hosts on the same LAN or by containers on the same node. For instance, a TCP service running on a node and listening on 127.0.0.1:1234 could be potentially reachable by other hosts or containers, posing a risk if the service does not require additional authentication. IPv6-only services on localhost are not affected by this issue.

Name of the Vulnerable Software and Affected Versions: containerd versions 1.2.0 through 1.2.13 Description: The issue is related to the incorrect handling of the image manifest in the containerd runtime environment. If a container image manifest includes a URL for a specific image layer, the default containerd resolver will follow that URL to attempt to download it. In versions 1.2.x, the default containerd resolver will provide its authentication credentials if the server where the URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. This allows an attacker to obtain the credentials used for pulling the image, which may include the user's username and password for the registry or credentials attached to the cloud virtual instance, granting access to other cloud resources in the account. Recommendations: For containerd versions 1.2.0 through 1.2.13, update to version 1.2.14 or later to fix the vulnerability. For users of cri-containerd in the 1.2 series or prior, ensure you only pull images from trusted sources. If you are using containerd 1.3 or later, you are not affected by this issue.

The issue is caused by improper input validation in the Kubernetes API server, allowing authorized users to send malicious YAML or JSON payloads. This can cause the API server to consume excessive CPU or memory, potentially crashing and becoming unavailable. In versions prior to v1.14.0, the default RBAC policy authorized anonymous users to submit requests that could trigger this vulnerability. Clusters upgraded from a version prior to v1.14.0 keep the more permissive policy by default for backwards compatibility. The vulnerability can be exploited through the API endpoint, allowing attackers to send malicious payloads, such as a "Billion Laughs" attack, which is a type of XML parsing issue that can cause excessive CPU usage.