Merge pull request #188 from kata-containers/KCSA-2020-28914

Add KCSA for CVE-2020-28914

VMT/KCSA.md

@@ -4,10 +4,11 @@ This page lists all previously published Kata Containers Security Advisories (KC
 
 This table is in reverse date order.
 
-| KCSA                                             | Description                  |
+| KCSA                                               | Description                  |
-| ------------------------------------------------ | ---------------------------- |
+| -------------------------------------------------- | ---------------------------- |
-| [KCSA-CVE-2019-5736](KCSA/KCSA-CVE-2019-5736.md) | runc container breakout      |
+| [KCSA-CVE-2020-28914](KCSA/KCSA-CVE-2020-28914.md) | Improper file permissions for read-only volumes |
-| [KCSA-CVE-2020-2024](KCSA/KCSA-CVE-2020-2024.md) | improper link resolution vulnerability |
+| [KCSA-CVE-2020-2023](KCSA/KCSA-CVE-2020-2023.md)   | Execution with Unnecessary Privileges |
-| [KCSA-CVE-2020-2025](KCSA/KCSA-CVE-2020-2025.md) | Cloud Hypervisor guest image persists vulnerability |
+| [KCSA-CVE-2020-2026](KCSA/KCSA-CVE-2020-2026.md)   | Improper Link Resolution Before File Access |
-| [KCSA-CVE-2020-2023](KCSA/KCSA-CVE-2020-2023.md) | Execution with Unnecessary Privileges |
+| [KCSA-CVE-2020-2024](KCSA/KCSA-CVE-2020-2024.md)   | improper link resolution vulnerability |
-| [KCSA-CVE-2020-2026](KCSA/KCSA-CVE-2020-2026.md) | Improper Link Resolution Before File Access |
+| [KCSA-CVE-2020-2025](KCSA/KCSA-CVE-2020-2025.md)   | Cloud Hypervisor guest image persists vulnerability |
+| [KCSA-CVE-2019-5736](KCSA/KCSA-CVE-2019-5736.md)   | runc container breakout      |

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

@@ -0,0 +1,71 @@
+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:
+
+  - CVE-ID: CVE-2020-28914
+
+reporters:
+
+  - name: `Alex Chapman`
+    affiliation: Independent Researcher
+    reported:
+      - CVE-2020-28914
+
+issues:
+
+  links:
+    - https://github.com/kata-containers/runtime/issues/3041
+    - https://github.com/kata-containers/kata-containers/issues/1061
+
+ reviews:
+
+  v2.0.0:
+    - https://github.com/kata-containers/kata-containers/pull/1062
+
+  v1.12.0:
+    - https://github.com/kata-containers/runtime/pull/3048
+
+  v1.11.5:
+    - https://github.com/kata-containers/runtime/pull/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.
+    1. Start a pod with a host-path volume passed as read-only to a container within the pod.
+    2. 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}/`
+    3. 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.
+