Hello Kubernetes Community,
A security issue was discovered in kubelet that could result in the Denial of Service of a node if a pod can write to its own /etc/hosts file.
This issue has been rated Medium (5.5, CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H/CR:H/IR:H/AR:M), and assigned CVE-2020-8557.
The /etc/hosts file mounted in a pod by kubelet is not included by the kubelet eviction manager when calculating ephemeral storage usage by a pod. If a pod writes a large amount of data to the /etc/hosts file, it could fill the storage space of the node and cause the node to fail.
Am I vulnerable?
Any clusters allowing pods with sufficient privileges to write to their own /etc/hosts files are affected. This includes containers running with CAP_DAC_OVERRIDE in their capabilities bounding set (true by default) and either UID 0 (root) or a security context with allowPrivilegeEscalation: true (true by default).
Affected Versions- kubelet v1.18.0-1.18.5
kubelet < v1.16.13
How do I mitigate this vulnerability?
PodSecurityPolicies or other admission webhooks could be employed to force containers to drop CAP_DAC_OVERRIDE or disallow running as root or with privilege escalation, but these measures may break existing workloads that rely upon these privileges to function properly.
Fixed Versions- kubelet v1.19.0
To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster
Large pod etc-hosts files may indicate that a pod is attempting to perform a Denial of Service attack using this bug. A command such as
find /var/lib/kubelet/pods/*/etc-hosts -size +1M
run on a node can be used to find abnormally large pod etc-hosts files.
See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/93032
This vulnerability was reported by Kebe Liu of DaoCloud
Joel Smith on behalf of the Kubernetes Product Security Committee