A hosts file escapes Kubernetes storage accounting

A file mounted into a container can consume node storage without belonging to the accounting paths used for that container's ordinary files. CVE-2020-8557 exposes that problem in the hosts file Kubernetes supplies to a pod. A container with permission to write the file can grow it until the node runs out of storage, while the kubelet's pod-level ephemeral storage calculation omits those bytes.

The July 15 security advisory rates the issue medium severity, with a score of 5.5. Its immediate impact is node denial of service. The flaw does not require a container escape. It uses a file the kubelet has already mounted into the pod, combined with permissions that allow the container to modify it.

I regard this as a useful example of why resource isolation needs accurate accounting as well as declared limits. Kubernetes can express a pod's storage budget, but that declaration depends on the kubelet connecting the relevant storage consumption to the correct pod. A missing file in that calculation leaves the intended policy incomplete.

The generated file is outside the old total

The public tracking issue describes the same accounting omission and credits Kebe Liu of DaoCloud with reporting the issue through the Kubernetes bug bounty program. The hosts file appears inside a container as /etc/hosts, but the kubelet maintains its backing file under the pod's directory on the node.

The fix in pull request 92916 makes that relationship explicit. It adds a function that obtains the generated hosts file path for a pod UID. The eviction manager receives that function and passes the resulting path into the helper that calculates local ephemeral storage use.

The helper already aggregates the selected categories of pod filesystem statistics. The patch adds a separate check of the hosts file. When a path is present and a file stat succeeds, it adds the file size to disk use and counts an inode. The correction therefore changes the input to an existing eviction decision. It does not solve the issue by making the hosts file universally immutable.

That implementation explains the security failure more precisely than saying that a pod can fill a disk. The problematic part is the mismatch between reachable writable storage and the consumption attributed to the pod. Node capacity remains finite, regardless of whether the pod's recorded ephemeral storage total includes the write.

Ordinary container privileges can be sufficient

The advisory identifies containers with CAP_DAC_OVERRIDE in their capabilities bounding set and either UID zero or permission for privilege escalation as affected examples. It notes that the capability and allowPrivilegeEscalation: true are defaults. The relevant question is whether the pod has sufficient permission to write its own hosts file.

This is a narrower condition than arbitrary code execution on the node. It is also broader than a policy that only looks for fully privileged containers. A workload can lack a privileged-container setting while retaining permissions relevant to this file. The advisory's conditions should therefore inform the assessment of exposure.

The suggested mitigation uses PodSecurityPolicies or admission webhooks to force dropping CAP_DAC_OVERRIDE, or to prohibit root execution and privilege escalation. The tracking issue makes clear that both root execution and privilege escalation need consideration in the latter approach. Removing one permission is useful only if the resulting security context actually prevents the write.

A container security-context fragment can express the capability restriction directly. It is an example of the advisory's mitigation, not a substitute for reviewing the complete pod policy.

securityContext:
  capabilities:
    drop:
      - DAC_OVERRIDE

The advisory warns that these restrictions may break workloads that depend on the removed privileges. That is an immediate compatibility issue for mitigation, distinct from the kubelet correction. An application that requires such privileges still needs the fixed accounting behavior on the node hosting it.

Detection examines the host-side file

The advisory gives a node-side command for finding unusually large hosts files. It searches the kubelet's per-pod backing files, not the operating system's own global hosts file.

find /var/lib/kubelet/pods/*/etc-hosts -size +1M

This command is an observation aid. A matching file may indicate an attempt to exploit the bug, as the advisory states. The threshold is not a published eviction limit or a proof of malicious intent. Interpreting a result requires relating the backing file to its pod and understanding why that workload wrote it.

Likewise, no matches do not establish that a node runs a corrected kubelet. Detection and version assessment answer different questions. The command looks for a visible symptom of the behavior, while the fix changes whether hosts-file consumption contributes to the storage decision.

The vulnerable component is the kubelet

The affected ranges in the advisory include kubelet v1.18.0 through v1.18.5, v1.17.0 through v1.17.8, and versions before v1.16.13. Corrected patch versions are v1.18.6, v1.17.9, and v1.16.13. The public issue links the corresponding backports as well as the main development fix. For a cluster containing different kubelet versions, that range needs to be applied to each node's version, because the vulnerable accounting happens locally.

Those ranges identify a node component. Updating an API endpoint alone does not establish that the kubelets on worker machines have changed. The security property depends on the implementation performing local pod storage accounting where the writable backing file lives.

The advisory also lists v1.19.0 as containing the correction. That entry describes the fix's inclusion in that version, not a reason to treat a future minor release as the only remediation path. The listed patch versions provide corrections on the existing release branches discussed in the notice.

My preference is to interpret storage limits through their enforcement mechanism. Here the substantive repair is visible in a small addition to the eviction calculation. The kubelet locates a pod's generated hosts file, obtains its size, and includes that consumption in the pod's local storage accounting. That closes the specific gap exploited by a container that can write the file.