containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows. In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host network containers. 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. This vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon as they are released. It should be noted that containers started with an old version of containerd-shim should be stopped and restarted, as running containers will continue to be vulnerable even after an upgrade. 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.

An update of the telegraf package has been released.

The version of containerd installed on the remote host is prior to 1.4.1-2. It is, therefore, affected by a vulnerability as referenced in the ALAS2ECS-2023-030 advisory.

    A flaw was found in containerd. Access controls for the shim 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. (CVE-2020-15257)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

According to the versions of the docker-engine packages installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - In containerd (an industry-standard container runtime) before version 1.2.14 there is a credential leaking     vulnerability. If a container image manifest in the OCI Image format or Docker Image V2 Schema 2 format     includes a URL for the location of a specific image layer (otherwise known as a foreign layer), the     default containerd resolver will follow that URL to attempt to download it. In v1.2.x but not 1.3.0 or     later, the default containerd resolver will provide its authentication credentials if the server where the     URL is located presents an HTTP 401 status code along with registry-specific HTTP headers. If an attacker     publishes a public image with a manifest that directs one of the layers to be fetched from a web server     they control and they trick a user or system into pulling the image, they can obtain the credentials used     for pulling that image. In some cases, this may be the user's username and password for the registry. In     other cases, this may be the credentials attached to the cloud virtual instance which can grant access to     other cloud resources in the account. The default containerd resolver is used by the cri-containerd plugin     (which can be used by Kubernetes), the ctr development tool, and other client programs that have     explicitly linked against it. This vulnerability has been fixed in containerd 1.2.14. containerd 1.3 and     later are not affected. If you are using containerd 1.3 or later, you are not affected. If you are using     cri-containerd in the 1.2 series or prior, you should ensure you only pull images from trusted sources.
    Other container runtimes built on top of containerd but not using the default resolver (such as Docker)     are not affected. (CVE-2020-15157)

  - containerd is an industry-standard container runtime and is available as a daemon for Linux and Windows.
    In containerd before versions 1.3.9 and 1.4.3, the containerd-shim API is improperly exposed to host     network containers. 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. This     vulnerability has been fixed in containerd 1.3.9 and 1.4.3. Users should update to these versions as soon     as they are released. It should be noted that containers started with an old version of containerd-shim     should be stopped and restarted, as running containers will continue to be vulnerable even after an     upgrade. 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. (CVE-2020-15257)

  - containerd is a container runtime. A bug was found in containerd versions prior to 1.4.8 and 1.5.4 where     pulling and extracting a specially-crafted container image can result in Unix file permission changes for     existing files in the host's filesystem. Changes to file permissions can deny access to the expected owner     of the file, widen access to others, or set extended bits like setuid, setgid, and sticky. This bug does     not directly allow files to be read, modified, or executed without an additional cooperating process. This     bug has been fixed in containerd 1.5.4 and 1.4.8. As a workaround, ensure that users only pull images from     trusted sources. Linux security modules (LSMs) like SELinux and AppArmor can limit the files potentially     affected by this bug through policies and profiles that prevent containerd from interacting with specific     files. (CVE-2021-32760)

  - containerd is an open source container runtime with an emphasis on simplicity, robustness and portability.
    A bug was found in containerd where container root directories and some plugins had insufficiently     restricted permissions, allowing otherwise unprivileged Linux users to traverse directory contents and     execute programs. When containers included executable programs with extended permission bits (such as     setuid), unprivileged Linux users could discover and execute those programs. When the UID of an     unprivileged Linux user on the host collided with the file owner or group inside a container, the     unprivileged Linux user on the host could discover, read, and modify those files. This vulnerability has     been fixed in containerd 1.4.11 and containerd 1.5.7. Users should update to these version when they are     released and may restart containers or update directory permissions to mitigate the vulnerability. Users     unable to update should limit access to the host to trusted users. Update directory permission on     container bundles directories. (CVE-2021-41103)

  - Moby is an open-source project created by Docker to enable and accelerate software containerization. A bug     was found in Moby (Docker Engine) prior to version 20.10.14 where containers were incorrectly started with     non-empty inheritable Linux process capabilities, creating an atypical Linux environment and enabling     programs with inheritable file capabilities to elevate those capabilities to the permitted set during     `execve(2)`. Normally, when executable programs have specified permitted file capabilities, otherwise     unprivileged users and processes can execute those programs and gain the specified file capabilities up to     the bounding set. Due to this bug, containers which included executable programs with inheritable file     capabilities allowed otherwise unprivileged users and processes to additionally gain these inheritable     file capabilities up to the container's bounding set. Containers which use Linux users and groups to     perform privilege separation inside the container are most directly impacted. This bug did not affect the     container security sandbox as the inheritable set never contained more capabilities than were included in     the container's bounding set. This bug has been fixed in Moby (Docker Engine) 20.10.14. Running containers     should be stopped, deleted, and recreated for the inheritable capabilities to be reset. This fix changes     Moby (Docker Engine) behavior such that containers are started with a more typical Linux environment. As a     workaround, the entry point of a container can be modified to use a utility like `capsh(1)` to drop     inheritable capabilities prior to the primary process starting. (CVE-2022-24769)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote host is affected by the vulnerability described in GLSA-202105-33 (containerd: Multiple vulnerabilities)

    Multiple vulnerabilities have been discovered in containerd. Please       review the CVE identifiers referenced below for details.
  Impact :

    A local attacker, able to run a malicious container in the same network       namespace as the shim, could possibly escalate privileges. Furthermore,       an attacker could disclose sensitive information.
  Workaround :

    There is no known workaround at this time.

An update of the containerd package has been released.

Multiple security issues were discovered in Docker, a Linux container runtime, which could result in denial of service, an information leak or privilege escalation.

This update for containerd, docker, docker-runc, golang-github-docker-libnetwork fixes the following issues :

Security issues fixed :

  - CVE-2020-15257: Fixed a privilege escalation in     containerd (bsc#1178969).

  - CVE-2021-21284: potential privilege escalation when the     root user in the remapped namespace has access to the     host filesystem (bsc#1181732)

  - CVE-2021-21285: pulling a malformed Docker image     manifest crashes the dockerd daemon (bsc#1181730)

Non-security issues fixed :

  - Update Docker to 19.03.15-ce. See upstream changelog in     the packaged     /usr/share/doc/packages/docker/CHANGELOG.md. This update     includes fixes for bsc#1181732 (CVE-2021-21284) and     bsc#1181730 (CVE-2021-21285).

  - Only apply the boo#1178801 libnetwork patch to handle     firewalld on openSUSE. It appears that SLES doesn't like     the patch. (bsc#1180401)

  - Update to containerd v1.3.9, which is needed for Docker     v19.03.14-ce and fixes CVE-2020-15257. bsc#1180243

  - Update to containerd v1.3.7, which is required for     Docker 19.03.13-ce. bsc#1176708

  - Update to Docker 19.03.14-ce. See upstream changelog in     the packaged     /usr/share/doc/packages/docker/CHANGELOG.md.
    CVE-2020-15257 bsc#1180243     https://github.com/docker/docker-ce/releases/tag/v19.03.
    14

  - Enable fish-completion

  - Add a patch which makes Docker compatible with firewalld     with nftables backend. Backport of     https://github.com/moby/libnetwork/pull/2548     (bsc#1178801, SLE-16460)

  - Update to Docker 19.03.13-ce. See upstream changelog in     the packaged     /usr/share/doc/packages/docker/CHANGELOG.md. bsc#1176708

  - Fixes for %_libexecdir changing to /usr/libexec     (bsc#1174075)

  - Emergency fix: %requires_eq does not work with provide     symbols, only effective package names. Convert back to     regular Requires.

  - Update to Docker 19.03.12-ce. See upstream changelog in     the packaged     /usr/share/doc/packages/docker/CHANGELOG.md.

  - Use Go 1.13 instead of Go 1.14 because Go 1.14 can cause     all sorts of spurrious errors due to Go returning -EINTR     from I/O syscalls much more often (due to Go 1.14's     pre-emptive goroutine support).

  - Add BuildRequires for all -git dependencies so that we     catch missing dependencies much more quickly.

  - Update to libnetwork 55e924b8a842, which is required for     Docker 19.03.14-ce. bsc#1180243

  - Add patch which makes libnetwork compatible with     firewalld with nftables backend. Backport of     https://github.com/moby/libnetwork/pull/2548     (bsc#1178801, SLE-16460)

This update was imported from the SUSE:SLE-15:Update update project.

This update for containerd, docker, docker-runc, golang-github-docker-libnetwork fixes the following issues :

Security issues fixed :

CVE-2020-15257: Fixed a privilege escalation in containerd (bsc#1178969).

CVE-2021-21284: potential privilege escalation when the root user in the remapped namespace has access to the host filesystem (bsc#1181732)

CVE-2021-21285: pulling a malformed Docker image manifest crashes the dockerd daemon (bsc#1181730)

Non-security issues fixed :

Update Docker to 19.03.15-ce. See upstream changelog in the packaged /usr/share/doc/packages/docker/CHANGELOG.md. This update includes fixes for bsc#1181732 (CVE-2021-21284) and bsc#1181730 (CVE-2021-21285).

Only apply the boo#1178801 libnetwork patch to handle firewalld on openSUSE. It appears that SLES doesn't like the patch. (bsc#1180401)

Update to containerd v1.3.9, which is needed for Docker v19.03.14-ce and fixes CVE-2020-15257. bsc#1180243

Update to containerd v1.3.7, which is required for Docker 19.03.13-ce.
bsc#1176708

Update to Docker 19.03.14-ce. See upstream changelog in the packaged /usr/share/doc/packages/docker/CHANGELOG.md. CVE-2020-15257 bsc#1180243 https://github.com/docker/docker-ce/releases/tag/v19.03.14

Enable fish-completion

Add a patch which makes Docker compatible with firewalld with nftables backend. Backport of https://github.com/moby/libnetwork/pull/2548 (bsc#1178801, SLE-16460)

Update to Docker 19.03.13-ce. See upstream changelog in the packaged /usr/share/doc/packages/docker/CHANGELOG.md. bsc#1176708

Fixes for %_libexecdir changing to /usr/libexec (bsc#1174075)

Emergency fix: %requires_eq does not work with provide symbols, only effective package names. Convert back to regular Requires.

Update to Docker 19.03.12-ce. See upstream changelog in the packaged /usr/share/doc/packages/docker/CHANGELOG.md.

Use Go 1.13 instead of Go 1.14 because Go 1.14 can cause all sorts of spurrious errors due to Go returning -EINTR from I/O syscalls much more often (due to Go 1.14's pre-emptive goroutine support).

Add BuildRequires for all -git dependencies so that we catch missing dependencies much more quickly.

Update to libnetwork 55e924b8a842, which is required for Docker 19.03.14-ce. bsc#1180243

Add patch which makes libnetwork compatible with firewalld with nftables backend. Backport of https://github.com/moby/libnetwork/pull/2548 (bsc#1178801, SLE-16460)

Note that Tenable Network Security has extracted the preceding description block directly from the SUSE security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

According to the version of the kata-containers package installed, the EulerOS installation on the remote host is affected by the following vulnerability :

  - containerd is an industry-standard container runtime     and is available as a daemon for Linux and Windows. In     containerd before versions 1.3.9 and 1.4.3, the     containerd-shim API is improperly exposed to host     network containers. 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. This vulnerability has     been fixed in containerd 1.3.9 and 1.4.3. Users should     update to these versions as soon as they are released.
    It should be noted that containers started with an old     version of containerd-shim should be stopped and     restarted, as running containers will continue to be     vulnerable even after an upgrade. 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.(CVE-2020-15257)

Note that Tenable Network Security has extracted the preceding description block directly from the EulerOS security advisory. Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4653-2 advisory.

    USN-4653-1 fixed a vulnerability in containerd. Unfortunately, those containerd packages introduced a     regression in docker.io and the update was reverted. This update addresses the docker.io issue and     reintroduces the fixes from USN-4653-1. We apologize for the inconvenience.

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Security fix for CVE-2020-15257

Note that Tenable Network Security has extracted the preceding description block directly from the Fedora update system website.
Tenable has attempted to automatically clean and format it as much as possible without introducing additional issues.

The remote Oracle Linux 7 host has packages installed that are affected by a vulnerability as referenced in the ELSA-2020-5966 advisory.

    - Fix for CVE-2020-15257
    - Fix for CVE-2020-15157
    - Address CVE-2020-16845
    - update to 19.03.11 for CVE-2020-13401
    - apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736
    - Fix for CVE-2020-15257
    - Fix for CVE-2020-15157
    - Address CVE-2020-16845
    - update to 19.03.11 for CVE-2020-13401
    - apply e4931e664feac6fa8846f3f04268a0cc98822549, fixes CVE-2019-5736

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Oracle Linux 7 host has a package installed that is affected by a vulnerability as referenced in the ELSA-2020-5964 advisory.

    - Addresses CVE-2020-15257

Tenable has extracted the preceding description block directly from the Oracle Linux security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

The remote Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS host has a package installed that is affected by a vulnerability as referenced in the USN-4653-1 advisory.

    It was discovered that access controls for the shims API socket did not restrict access to the abstract     unix domain socket in some cases. An attacker could use this vulnerability to run containers with elevated     privileges.

Tenable has extracted the preceding description block directly from the Ubuntu security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

It is, therefore, affected by a vulnerability as referenced in the ALAS-2020-1455 advisory.

    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. (CVE-2020-15257)

Tenable has extracted the preceding description block directly from the tested product security advisory.

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Severity
204388	Photon OS 5.0: Telegraf PHSA-2023-5.0-0041	Nessus	PhotonOS Local Security Checks	high
185923	Amazon Linux 2 : containerd (ALASECS-2023-030)	Nessus	Amazon Linux Local Security Checks	medium
162362	EulerOS 2.0 SP5 : docker-engine (EulerOS-SA-2022-1886)	Nessus	Huawei Local Security Checks	high
156977	GLSA-202105-33 : containerd: Multiple vulnerabilities	Nessus	Gentoo Local Security Checks	medium
148345	Photon OS 4.0: Containerd PHSA-2021-4.0-0007	Nessus	PhotonOS Local Security Checks	medium
146922	Debian DSA-4865-1 : docker.io - security update	Nessus	Debian Local Security Checks	medium
146506	openSUSE Security Update : containerd / docker / docker-runc / etc (openSUSE-2021-278)	Nessus	SuSE Local Security Checks	medium
146460	SUSE SLES15 Security Update : containerd, docker, docker-runc, golang-github-docker-libnetwork (SUSE-SU-2021:0435-1)	Nessus	SuSE Local Security Checks	medium
146252	EulerOS 2.0 SP9 : kata-containers (EulerOS-SA-2021-1245)	Nessus	Huawei Local Security Checks	medium
146231	EulerOS 2.0 SP9 : kata-containers (EulerOS-SA-2021-1264)	Nessus	Huawei Local Security Checks	medium
145013	Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : containerd vulnerability (USN-4653-2)	Nessus	Ubuntu Local Security Checks	medium
144042	Fedora 33 : containerd (2020-baeb8dbaea)	Nessus	Fedora Local Security Checks	medium
143486	Oracle Linux 7 : docker-cli / docker-engine (ELSA-2020-5966)	Nessus	Oracle Linux Local Security Checks	medium
143451	Oracle Linux 7 : containerd (ELSA-2020-5964)	Nessus	Oracle Linux Local Security Checks	medium
143448	Photon OS 3.0: Containerd PHSA-2020-3.0-0168	Nessus	PhotonOS Local Security Checks	medium
143446	Photon OS 2.0: Containerd PHSA-2020-2.0-0301	Nessus	PhotonOS Local Security Checks	medium
143373	Ubuntu 16.04 LTS / 18.04 LTS / 20.04 LTS : containerd vulnerability (USN-4653-1)	Nessus	Ubuntu Local Security Checks	medium
143367	Amazon Linux AMI : containerd, containerd-stress (ALAS-2020-1455)	Nessus	Amazon Linux Local Security Checks	medium

Detections

Analytics

CVE-2020-15257

medium

Tenable Plugins

high

medium

high

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium

medium