Access controls for the shim's API socket verified that the connecting process had an effective UID of 0, but did not otherwise restrict access to the abstract Unix domain socket. This would allow malicious containers running in the same network namespace as the shim, with an effective UID of 0 but otherwise reduced privileges, to cause new processes to be run with elevated privileges.
Created attachment 1730902 [details] patch 1.3
Created attachment 1730903 [details] patch 1.4
Workaround described by upstream: If you are not providing the ability for untrusted users to start containers in the same network namespace as the shim (typically the "host" network namespace, for example with `docker run --net=host` or `hostNetwork: true` in a Kubernetes pod) and run with an effective UID of 0, you are not vulnerable to this issue. If you are running containers with a vulnerable configuration, you can deny access to all abstract sockets with AppArmor by adding a line similar to `deny unix addr=@**,` to your policy. It is best practice to run containers with a reduced set of privileges, with a non-zero UID, and with isolated namespaces. The containerd maintainers strongly advise against sharing namespaces with the host. Reducing the set of isolation mechanisms used for a container necessarily increases that container's privilege, regardless of what container runtime is used for running that container.
The patches in comment 2 and comment 3 change the default interpretation of the "socket" configuration (path to control socket) to represent a filesystem path rather than an abstract path. The filesystem-based socket will be protected with chmod(0600) (and permissions/facls applying to its parent directory), which is not possible for abstract sockets. An abstract socket may still be specified with the "unix://" prefix, but this SHOULD BE AVOIDED as it can not be protected by filesystem permissions and this vulnerability will be exposed.
In reply to comment #4: > The patches in comment 2 and comment 3 change the default interpretation of > the "socket" configuration (path to control socket) to represent a > filesystem path rather than an abstract path. The filesystem-based socket > will be protected with chmod(0600) (and permissions/facls applying to its > parent directory), which is not possible for abstract sockets. > > An abstract socket may still be specified with the "unix://" prefix, but > this SHOULD BE AVOIDED as it can not be protected by filesystem permissions > and this vulnerability will be exposed. The socket path is not configurable but is hardcoded to /run/containerd/s. The socket is assigned 600 file permissions which will provide adequate protection.
Created containerd tracking bugs for this issue: Affects: epel-7 [bug 1903051] Affects: fedora-all [bug 1903050]
Statement: The container runtime in OpenShift Container Platform 4 is cri-o which is not affected by this flaw. It doesn't make use of abstract unix sockets like containerd, which lead to this vulnerability being possible. Red Hat Advanced Cluster Management for Kubernetes is not affected by this flaw. While containerd is included in the multicloud-operators-subscription image as a dependency of helm, it is not used in any way that exposes the abstract unix socket that is involved in this vulnerability. The container-tools module in Red Hat Enterprise Linux is not affected by this flaw as these packages do not use abstract unix sockets for container management.
This bug should not affect Openshift Container Platform 3 with docker as a container runtime, as access to abstract unix sockets on the host by container processes is blocked by SELinux.
This issue has been addressed in the following products: Red Hat OpenStack Platform 16.2 Via RHSA-2022:2183 https://access.redhat.com/errata/RHSA-2022:2183
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s): https://access.redhat.com/security/cve/cve-2020-15257