From 1d7c06454aa5039eeb2893a08b60297406cd9968 Mon Sep 17 00:00:00 2001 From: Archana Shinde Date: Wed, 18 Nov 2020 09:54:59 -0800 Subject: [PATCH] VMT: add KCSA for CVE-2020-28914 We have fixed them and put the fix in a release. Let's make the announcement. Fixes: #187 Signed-off-by: Archana Shinde --- VMT/KCSA/KCSA-CVE-2020-28914.md | 71 +++++++++++++++++++++++++++++++++ 1 file changed, 71 insertions(+) create mode 100644 VMT/KCSA/KCSA-CVE-2020-28914.md diff --git a/VMT/KCSA/KCSA-CVE-2020-28914.md b/VMT/KCSA/KCSA-CVE-2020-28914.md new file mode 100644 index 0000000000..115974cf87 --- /dev/null +++ b/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. +