[Security Advisory] CVE-2020-8557: Node disk DOS by writing to container /etc/hosts

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.17.0-1.17.8

  • 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

  • kubelet v1.18.6

  • kubelet v1.17.9

  • kubelet v1.16.13

To upgrade, refer to the documentation: https://kubernetes.io/docs/tasks/administer-cluster/cluster-management/#upgrading-a-cluster

Detection

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.

Additional Details

See the GitHub issue for more details: https://github.com/kubernetes/kubernetes/issues/93032

Acknowledgements

This vulnerability was reported by Kebe Liu of DaoCloud

Thank you,

Joel Smith on behalf of the Kubernetes Product Security Committee