Merge pull request #158 from amshinde/KCSA-2023-2026

VMT: add KCSA for CVE-2020-2023 and CVE-2020-2026

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 |

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.

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.