announcement-date: 2020-11-17
id: KCSA-CVE-2020-28914
title: Kata Containers Improper file permissions for read-only volumes
description: An improper file permissions vulnerability affects Kata Containers
prior to 1.11.5. When using a Kubernetes host-path volume and mounting
either a file or directory into a container as readonly, the file/directory
is mounted as read-only inside the container, but is still writable inside
the guest. For a container breakout situation, a malicious guest can
potentially modify or delete files/directories expected to be read-only.
affected-components:
- components:
kata-runtime
version: Before v1.11.5
vulnerabilities:
reporters:
- name:
Alex Chapman
affiliation: Independent Researcher
reported:
issues:
links:
– kata-containers/runtime#3041
– kata-containers/kata-containers#1061
reviews:
v2.0.0:
– kata-containers/kata-containers#1062
v1.12.0:
– kata-containers/runtime#3048
v1.11.5:
– kata-containers/runtime#3051
type: GitHub
reproduce:
-
When using a Kubernetes host-path volume and mounting either a file or
directory into a container with read-only: true, the file/directory is
mounted as read-only inside the container, but is still writable inside
the guest (but outside of the container).In case a container breakout were to occur, a malicious guest will be able to
modify or delete files and directories that are expected to be read-only inside
the guest.- Start a pod with a host-path volume passed as read-only to a container within the pod.
- Start a debug shell to get root access within the guest and attempt
to write to the read-only volume shared with the guest under
/run/kata-containers/shared/sandboxes/{pod-id}/{volume}/ - Though the volume is not writable within the container, the guest will be
able to write to the volume or even delete it.
notes:
- If the read-only files/directories are shared across multiple
pods on the same node, other pods will be able to see the modified/deleted files/directories.
This vulnerability has been fixed in releases 1.12.0, 1.11.5 and 2.0 branch.