From 17c91ca36a3aee7e99a0b951aa9468d3015d5649 Mon Sep 17 00:00:00 2001 From: Archana Shinde Date: Sat, 13 Jun 2020 00:57:52 -0700 Subject: [PATCH] VMT: add KCSA for CVE-2020-2023 and CVE-2020-2026 These have been fixed and put in releases 1.11.1 and 1.10.5. Sending out announcement. Fixes #159 Signed-off-by: Archana Shinde --- VMT/KCSA.md | 2 + VMT/KCSA/KCSA-CVE-2020-2023.md | 69 ++++++++++++++++++++++++ VMT/KCSA/KCSA-CVE-2020-2026.md | 98 ++++++++++++++++++++++++++++++++++ 3 files changed, 169 insertions(+) create mode 100644 VMT/KCSA/KCSA-CVE-2020-2023.md create mode 100644 VMT/KCSA/KCSA-CVE-2020-2026.md diff --git a/VMT/KCSA.md b/VMT/KCSA.md index da329f480e..3aedc2fa29 100644 --- a/VMT/KCSA.md +++ b/VMT/KCSA.md @@ -9,3 +9,5 @@ This table is in reverse date order. | [KCSA-CVE-2019-5736](KCSA/KCSA-CVE-2019-5736.md) | runc container breakout | | [KCSA-CVE-2020-2024](KCSA/KCSA-CVE-2020-2024.md) | improper link resolution vulnerability | | [KCSA-CVE-2020-2025](KCSA/KCSA-CVE-2020-2025.md) | Cloud Hypervisor guest image persists vulnerability | +| [KCSA-CVE-2020-2023](KCSA/KCSA-CVE-2020-2023.md) | Execution with Unnecessary Privileges | +| [KCSA-CVE-2020-2026](KCSA/KCSA-CVE-2020-2026.md) | Improper Link Resolution Before File Access | diff --git a/VMT/KCSA/KCSA-CVE-2020-2023.md b/VMT/KCSA/KCSA-CVE-2020-2023.md new file mode 100644 index 0000000000..1d1b033359 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2023.md @@ -0,0 +1,69 @@ +announcement-date: 2020-06-12 + +id: KCSA-CVE-2020-2023 + +title: Kata Containers Execution with Unnecessary Privileges + +description: A container can access the guest root file system device. +This can be used to gain code execution on the guest and masquerade as `kata-agent`. + +affected-components: + + - components: `kata-agent` + version: Before v1.11.1 + +vulnerabilities: + + - CVE-ID: CVE-2020-2023 + +reporters: + + - name: `Yuval Avrahami` + affiliation: `Palo Alto Networks` + reported: + - CVE-2020-2023 + +issues: + + links: + - https://github.com/kata-containers/agent/issues/791 + - https://github.com/kata-containers/runtime/issues/2476 + - https://github.com/kata-containers/runtime/issues/2488 + + reviews: + + v1.11.1: + - https://github.com/kata-containers/agent/pull/792 + - https://github.com/kata-containers/runtime/pull/2477 + - https://github.com/kata-containers/runtime/pull/2487 + + type: GitHub + +reproduce: + + - A malicious container can create a device file for the guest root filesystem + device, and use it to modify the guest filesystem through utilities + like [`debugfs`](https://linux.die.net/man/8/debugfs), potentially allowing + a container-to-guest breakout: + + 1. Find the guest root filesystem device major and minor numbers by inspecting `/sys/dev/block`. + 2. Use`mknod` to create a device file for the guest root filesystem device. + 3. Use utilities such as `debugfs` to access the device file and modify the guest filesystem. + 4. Attempt to gain code execution on the guest by overwriting crucial guest files (e.g. `kata-agent`, `libc`) + + When the guest filesystem is mounted with [DAX](https://www.kernel.org/doc/Documentation/filesystems/dax.txt), + it's easier for the container to gain guest code execution. With DAX, + changes made to the device immediately propagate to the pages used by guest + processes. This means the container can inject code to guest processes by + modifying the executables and libraries used by them. + + Without DAX, the malicious container can force changes made to the device to + propagate to guest pages by exhausting memory, forcing the guest kernel to + re-read the pages from the compromised device. The attack may fail if the + container memory is limited by cgroups. + +notes: + - The vulnerability can be used to compromise the guest and masquerade + as the `kata-agent`. To exploit the issue, the container must + possess `CAP_MKNOD` capability. + All users are recommended to upgrade to mitigate guest breakout. diff --git a/VMT/KCSA/KCSA-CVE-2020-2026.md b/VMT/KCSA/KCSA-CVE-2020-2026.md new file mode 100644 index 0000000000..4947216912 --- /dev/null +++ b/VMT/KCSA/KCSA-CVE-2020-2026.md @@ -0,0 +1,98 @@ +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: + - https://github.com/kata-containers/runtime/issues/2712 + + reviews: + + v1.11.0: + - https://github.com/kata-containers/runtime/pull/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.