KCSA-CVE-2020-2026.md

announcement-date: 2020-06-12

id: KCSA-CVE-2020-2026

title: Kata Containers Improper Link Resolution Before File Access

description: A malicious guest compromised before a container creation (e.g. a malicious guest image or a guest running multiple containers) can trick the kata-runtime into mounting the untrusted container filesystem on any host path, potentially allowing for code execution on the host. This issue affects: Kata Containers 1.11 versions earlier than 1.11.1; Kata Containers 1.10 versions earlier than 1.10.5.

affected-components:

• components: kata-runtime version: Before v1.11.1, v1.10.5

vulnerabilities:

• CVE-ID: CVE-2020-2026

reporters:

• name: Yuval Avrahami affiliation: Palo Alto Networks reported:
  • CVE-2020-2026

issues:

links: - kata-containers/runtime#2712

reviews:

v1.11.0: - kata-containers/runtime#2713

type: GitHub

reproduce:

• A malicious guest compromised before a container creation (e.g. a malicious guest image or a guest running multiple containers) can trick the kata-runtime
  into mounting the untrusted container filesystem on any host path.

  When Kata Containers is configured with overlay2 as storage driver, a malicious guest can create a symbolic link in the shared directory at /run/kata-containers/shared/containers/${ctrid}/rootfs to a target directory on the host. Upon container creation, the kata-runtime will be tricked into bind mounting the container filesystem at the target directory on the host.

  To create the symbolic link the guest must know the container id as it’s a part of the mount’s target path. The first container in a sandbox is unique in that regard since its id is the sandbox id, which is known to the guest at the time of the mount. If a guest is compromised before the first container is added to it (e.g. a malicious guest image), it can execute the following attack in case of overlay file systems:

  1. The malicious guest receives the CreateSandbox message and extracts the sandbox id from it. The first container id matches the sandbox id and is derived from that message.
  2. The malicious guest creates the malicious symbolic link at the shared directory, at /run/kata-containers/shared/containers/${first_ctrid}/rootfs
  3. The malicious guest returns a response for CreateSandbox
  4. Once the kata-runtime on the host receives the CreateSandbox response, it tries to bind mount the container image at /run/kata-containers/shared/sandbox/$sbx_id/${first_ctrid}/rootfs
  5. The malicious symbolic link redirects the mount operation to the target on the host.

  In case of non initial container images, the guest does not know the container id. In case of volume mounts and mounts related to platform-specific files such as /etc/hosts, the mounts are performed in the shared directory on paths that are not known to the guest. The guest would need to win a race condition between ensureDestinationExists function called by kata-runtime that creates the file or directory that is to be mounted on and bind mount done after calling ensureDestinationExists.

  Between those steps, the guest must replace the created file or directory with a symbolic link to a target on the host.

notes:

• Given that the container image is malicious, the guest can gain code execution on the host by mounting over directories such as /bin or /lib. Besides code execution, the host can be DOSed as well (by mounting over crucial directories).

  In the case of overlay2 mounts, once the container engine (e.g. Docker) removes the container, it might also delete the lower layers of the container filesystem, rendering the mount done through this attack empty. In the case of mounting the malicious container image over /bin, if no process tried running a binary from /bin before the container is removed, then /bin will become empty, and the attack fails. To deal with the above, an attacker could target /lib or /lib64, which contains libraries for dynamically linked binaries such as the kata-runtime itself. Under Docker for example, the kata-runtime will most likely be executed again in the process of spawning a container. The libraries loaded and executed by the kata-runtime process would then be malicious.

  With Kubernetes, there can be multiple containers in a guest, but the first is always the pause container. An attack redirecting the pause container is limited to a host DoS since the pause container image isn't malicious. An attack redirecting container volumes or platform-specific mounts is most likely limited to a DoS since the content of these mounts isn't malicious.