Bug 1899487 (CVE-2020-15257) - CVE-2020-15257 containerd: unrestricted access to abstract Unix domain socket can lead to privileges escalation
Summary: CVE-2020-15257 containerd: unrestricted access to abstract Unix domain socket...
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-15257
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On: 1899812 1899813 1899814 1903050 1903051 2032712 2032713 2032714
Blocks: 1899489
TreeView+ depends on / blocked
 
Reported: 2020-11-19 12:04 UTC by Marian Rehak
Modified: 2024-03-25 17:09 UTC (History)
29 users (show)

Fixed In Version: containerd 1.3.9, containerd 1.4.3
Doc Type: If docs needed, set a value
Doc Text:
A flaw was found in containerd. Access controls for the shim's API socket verified that a connecting process had an effective UID of 0, but otherwise did not restrict access to the abstract Unix domain socket. This could 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. The highest threat from this vulnerability is to data confidentiality and integrity as well as system availability.
Clone Of:
Environment:
Last Closed: 2022-05-12 10:15:17 UTC
Embargoed:


Attachments (Terms of Use)
patch 1.3 (22.17 KB, patch)
2020-11-19 12:06 UTC, Marian Rehak
no flags Details | Diff
patch 1.4 (21.58 KB, patch)
2020-11-19 12:07 UTC, Marian Rehak
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2022:2183 0 None None None 2022-05-11 11:34:26 UTC

Description Marian Rehak 2020-11-19 12:04:15 UTC
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.

Comment 1 Marian Rehak 2020-11-19 12:06:29 UTC
Created attachment 1730902 [details]
patch 1.3

Comment 2 Marian Rehak 2020-11-19 12:07:05 UTC
Created attachment 1730903 [details]
patch 1.4

Comment 3 Doran Moppert 2020-11-20 02:29:25 UTC
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.

Comment 4 Doran Moppert 2020-11-20 02:54:04 UTC
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.

Comment 10 Jason Shepherd 2020-11-27 01:54:58 UTC
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.

Comment 11 Marian Rehak 2020-12-01 08:33:47 UTC
Created containerd tracking bugs for this issue:

Affects: epel-7 [bug 1903051]
Affects: fedora-all [bug 1903050]

Comment 12 Eric Christensen 2020-12-01 19:11:31 UTC
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.

Comment 16 Peter Hunt 2020-12-09 17:56:22 UTC
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.

Comment 22 errata-xmlrpc 2022-05-11 11:34:23 UTC
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

Comment 23 Product Security DevOps Team 2022-05-12 10:15:13 UTC
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


Note You need to log in before you can comment on or make changes to this bug.