Merge pull request #156 from bergwolf/vmt

VMT: add KCSAs for CVE-2020-2024 and CVE-2020-2025

VMT/KCSA.md

@@ -7,3 +7,5 @@ This table is in reverse date order.
 | KCSA                                             | Description                  |
 | ------------------------------------------------ | ---------------------------- |
 | [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 |

VMT/KCSA/KCSA-CVE-2020-2024.md

@@ -0,0 +1,68 @@
+announcement-date: 2020-05-28
+
+id: KCSA-CVE-2020-2024
+
+title: Kata Containers improper link resolution vulnerability
+
+description: An improper link resolution vulnerability affects Kata Containers
+versions prior to 1.11.0. Upon container teardown, a malicious guest can trick
+the `kata-runtime` into unmount any mount point on the host and all mount
+points underneath it, potentiality resulting in a host DoS.
+
+affected-components:
+
+  - components: `kata-runtime`
+    version: Before v1.11.0
+
+vulnerabilities:
+
+  - CVE-ID: CVE-2020-2024
+
+reporters:
+
+  - name: `Yuval Avrahami`
+    affiliation: `Palo Alto Networks`
+    reported:
+      - CVE-2020-2024
+
+issues:
+
+  links:
+    - https://github.com/kata-containers/runtime/issues/2474
+
+ reviews:
+
+  v1.11.0:
+    - https://github.com/kata-containers/runtime/pull/2475
+
+  type: GitHub
+
+reproduce:
+  - When Kata Containers is configured with overlay2 as the storage driver, the
+    attack follows the steps below (all actions are executed by the malicious
+    guest):
+    1. Rename `/run/kata-containers/shared/containers/${ctr-id}` to `/run/kata-containers/shared/containers/${ctr-id}_original_`
+    2. Then, recreate `/run/kata-containers/shared/containers/${ctr-id}`
+    3. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs`
+
+    For devicemapper:
+    1. Unmount `/run/kata-containers/shared/containers/${ctr-id}`
+    2. Create a `symlink` to the host target mount named `/run/kata-containers/shared/containers/${ctr-id}/rootfs`
+
+notes:
+  - The vulnerability can be used to attack the host by malicious containers
+    that find other ways to gain control over the guest. And all users are
+    recommended to upgrade.
+
+    The unmount operation is done with the MNT_DETACH flag, meaning that mount
+    points under the target mount will be unmounted as well. Because of that,
+    if we target ‘/’ in our attack, then the host mounts underneath it (e.g.,
+    `/proc`, `/sys`, etc.) will be unmounted as well, resulting in the host being
+    non-functional in most scenarios (e.g. being a `kubernetes` node), creating
+    a Denial of Service.
+
+    On `kubernetes`, a malicious guest can trigger multiple container deletions
+    by simply killing the container processes running on it. With the default
+    `kubernetes` restart policy, containers will be removed and recreated. This
+    process can be repeated by the malicious guest several times to control
+    multiple unmount operations on the host.

VMT/KCSA/KCSA-CVE-2020-2025.md

@@ -0,0 +1,62 @@
+announcement-date: 2020-05-28
+
+id: KCSA-CVE-2020-2025
+
+title: Kata Containers with Cloud Hypervisor guest image persists vulnerability
+
+description: Kata Containers before 1.11.0 on Cloud Hypervisor persists guest
+filesystem changes to the underlying image file on the host. A malicious guest
+can overwrite the image file to gain control of all subsequent guest VMs.
+Since Kata Containers uses the same VM image file with all VMMs, this issue
+may also affect QEMU and Firecracker based guests.
+
+affected-components:
+
+  - components: `kata-runtime`
+    version: Before v1.11.0
+
+vulnerabilities:
+
+  - CVE-ID: CVE-2020-2025
+
+reporters:
+
+  - name: `Yuval Avrahami`
+    affiliation: `Palo Alto Networks`
+    reported:
+      - CVE-2020-2025
+
+issues:
+
+  links:
+    - https://github.com/kata-containers/runtime/issues/2488
+
+ reviews:
+
+  v1.11.0:
+    - https://github.com/kata-containers/runtime/pull/2487
+
+  type: GitHub
+
+reproduce:
+  - Create a Kata Container using Cloud Hypervisor
+  - Create a new file on the guest rootfs
+  - View the guest rootfs image on the host and the file can be seen there
+
+notes:
+  - The vulnerability can be used to attack other guests by malicious containers
+    that find other ways to gain control over the guest. And all users running
+    Kata Containers on top of Cloud Hypervisor are recommended to upgrade.
+
+    When running Kata Containers with Cloud Hypervisor, any change made to root
+    filesystem device is written to the underlying `.img` file. Since the device
+    is plugged as read-write, a malicious guest could write to it and the changes
+    will propagate to the image file on the host.
+
+    Compromising the guest image file allows an attacker to control all
+    subsequent guests that run that image. Since, by default, the same guest
+    image file is used by all VMMs (QEMU, Firecracker and Cloud Hypervisor),
+    the next time any guest is executed, it will be malicious. This immediately
+    compromises all subsequent container runs. Additionally, it can expose the
+    host to attacks that require the guest to be malicious from the moment it
+    boots.