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

    - Address CVE-2021-32760

    docker-cli
    - updated containerd minimum version to 1.4.8 to address CVE-2021-32760.

    docker-engine

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.

An update of the containerd package has been released.

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

    - Address CVE-2021-32760

    docker-cli
    - updated containerd minimum version to 1.4.8 to address CVE-2021-32760.

    docker-engine

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 SUSE Linux SUSE15 host has packages installed that are affected by a vulnerability as referenced in the openSUSE-SU-2021:2412-1 advisory.

  - 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 hosts 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)

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)

  - In Docker before versions 9.03.15, 20.10.3 there is a vulnerability involving the --userns-remap option in     which access to remapped root allows privilege escalation to real root. When using '--userns-remap', if     the root user in the remapped namespace has access to the host filesystem they can modify files under     '/var/lib/docker/<remapping>' that cause writing files with extended privileges. Versions 20.10.3 and     19.03.15 contain patches that prevent privilege escalation from remapped user. (CVE-2021-21284)

  - 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)

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.

An update of the telegraf package has been released.

The remote SUSE Linux SLES15 / SLES_SAP15 host has packages installed that are affected by multiple vulnerabilities as referenced in the SUSE-SU-2021:3506-1 advisory.

    Docker was updated to 20.10.9-ce. (bsc#1191355)

    See upstream changelog in the packaged       /usr/share/doc/packages/docker/CHANGELOG.md.

      CVE-2021-41092 CVE-2021-41089 CVE-2021-41091 CVE-2021-41103

    container was updated to v1.4.11, to fix CVE-2021-41103. bsc#1191355

    - CVE-2021-32760: Fixed that a archive package allows chmod of file outside of unpack target directory     (bsc#1188282)

    - Install systemd service file as well (bsc#1190826)

    Update to runc v1.0.2. Upstream changelog is available from

      https://github.com/opencontainers/runc/releases/tag/v1.0.2

    * Fixed a failure to set CPU quota period in some cases on cgroup v1.
    * Fixed the inability to start a container with the 'adding seccomp filter       rule for syscall ...' error, caused by redundant seccomp rules (i.e. those       that has action equal to the default one). Such redundant rules are now       skipped.
    * Made release builds reproducible from now on.
    * Fixed a rare debug log race in runc init, which can result in occasional       harmful 'failed to decode ...' errors from runc run or exec.
    * Fixed the check in cgroup v1 systemd manager if a container needs to be       frozen before Set, and add a setting to skip such freeze unconditionally.
      The previous fix for that issue, done in runc 1.0.1, was not working.

    Update to runc v1.0.1. Upstream changelog is available from

    https://github.com/opencontainers/runc/releases/tag/v1.0.1

    * Fixed occasional runc exec/run failure ('interrupted system call') on an       Azure volume.
    * Fixed 'unable to find groups ... token too long' error with /etc/group       containing lines longer than 64K characters.
    * cgroup/systemd/v1: fix leaving cgroup frozen after Set if a parent cgroup is       frozen. This is a regression in 1.0.0, not affecting runc itself but some       of libcontainer users (e.g Kubernetes).
    * cgroupv2: bpf: Ignore inaccessible existing programs in case of       permission error when handling replacement of existing bpf cgroup       programs. This fixes a regression in 1.0.0, where some SELinux       policies would block runc from being able to run entirely.
    * cgroup/systemd/v2: don't freeze cgroup on Set.
    * cgroup/systemd/v1: avoid unnecessary freeze on Set.
    - fix issues with runc under openSUSE MicroOS's SELinux policy. bsc#1187704

    Update to runc v1.0.0. Upstream changelog is available from

    https://github.com/opencontainers/runc/releases/tag/v1.0.0

    ! The usage of relative paths for mountpoints will now produce a warning       (such configurations are outside of the spec, and in future runc will       produce an error when given such configurations).
    * cgroupv2: devices: rework the filter generation to produce consistent       results with cgroupv1, and always clobber any existing eBPF       program(s) to fix runc update and avoid leaking eBPF programs       (resulting in errors when managing containers).
    * cgroupv2: correctly convert 'number of IOs' statistics in a       cgroupv1-compatible way.
    * cgroupv2: support larger than 32-bit IO statistics on 32-bit architectures.
    * cgroupv2: wait for freeze to finish before returning from the freezing       code, optimize the method for checking whether a cgroup is frozen.
    * cgroups/systemd: fixed 'retry on dbus disconnect' logic introduced in rc94
    * cgroups/systemd: fixed returning 'unit already exists' error from a systemd       cgroup manager (regression in rc94)     + cgroupv2: support SkipDevices with systemd driver     + cgroup/systemd: return, not ignore, stop unit error from Destroy     + Make 'runc --version' output sane even when built with go get or       otherwise outside of our build scripts.
    + cgroups: set SkipDevices during runc update (so we don't modify       cgroups at all during runc update).
    + cgroup1: blkio: support BFQ weights.
    + cgroupv2: set per-device io weights if BFQ IO scheduler is available.

    Update to runc v1.0.0~rc95. Upstream changelog is available from     https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc95

    This release of runc contains a fix for CVE-2021-30465, and users are     strongly recommended to update (especially if you are providing     semi-limited access to spawn containers to untrusted users). (bsc#1185405)

    Update to runc v1.0.0~rc94. Upstream changelog is available from     https://github.com/opencontainers/runc/releases/tag/v1.0.0-rc94

    Breaking Changes:
    * cgroupv1: kernel memory limits are now always ignored, as kmemcg has       been effectively deprecated by the kernel. Users should make use of regular       memory cgroup controls.

    Regression Fixes:

    * seccomp: fix 32-bit compilation errors
    * runc init: fix a hang caused by deadlock in seccomp/ebpf loading code
    * runc start: fix 'chdir to cwd: permission denied' for some setups

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

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

The remote host is affected by the vulnerability described in GLSA-202401-31 (containerd: Multiple Vulnerabilities)

  - 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)

  - containerd is an open source container runtime. A bug was found in containerd's CRI implementation where a     user can exhaust memory on the host. In the CRI stream server, a goroutine is launched to handle terminal     resize events if a TTY is requested. If the user's process fails to launch due to, for example, a faulty     command, the goroutine will be stuck waiting to send without a receiver, resulting in a memory leak.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation and the stream server     is used for handling container IO. This bug has been fixed in containerd 1.6.12 and 1.5.16. Users should     update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted     images and commands are used and that only trusted users have permissions to execute commands in running     containers. (CVE-2022-23471)

  - containerd is a container runtime available as a daemon for Linux and Windows. A bug was found in     containerd prior to versions 1.6.1, 1.5.10, and 1.14.12 where containers launched through containerd's CRI     implementation on Linux with a specially-crafted image configuration could gain access to read-only copies     of arbitrary files and directories on the host. This may bypass any policy-based enforcement on container     setup (including a Kubernetes Pod Security Policy) and expose potentially sensitive information.
    Kubernetes and crictl can both be configured to use containerd's CRI implementation. This bug has been     fixed in containerd 1.6.1, 1.5.10, and 1.4.12. Users should update to these versions to resolve the issue.
    (CVE-2022-23648)

  - 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)

  - containerd is an open source container runtime. A bug was found in the containerd's CRI implementation     where programs inside a container can cause the containerd daemon to consume memory without bound during     invocation of the `ExecSync` API. This can cause containerd to consume all available memory on the     computer, denying service to other legitimate workloads. Kubernetes and crictl can both be configured to     use containerd's CRI implementation; `ExecSync` may be used when running probes or when executing     processes via an exec facility. This bug has been fixed in containerd 1.6.6 and 1.5.13. Users should     update to these versions to resolve the issue. Users unable to upgrade should ensure that only trusted     images and commands are used. (CVE-2022-31030)

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

The remote SUSE Linux SLES12 host has a package installed that is affected by a vulnerability as referenced in the SUSE- SU-2021:2413-1 advisory.

    - CVE-2021-32760: Fixed a bug which allows untrusted container images to change permissions in the host's     filesystem. (bsc#1188282)

Tenable has extracted the preceding description block directly from the SUSE 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 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.

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
162816	Oracle Linux 7 : containerd (ELSA-2021-15790)	Nessus	Oracle Linux Local Security Checks	2022/7/7	2024/10/23	medium
151960	Photon OS 4.0: Containerd PHSA-2021-4.0-0064	Nessus	PhotonOS Local Security Checks	2021/7/22	2024/7/23	medium
152049	Oracle Linux 7 : containerd (ELSA-2021-9373)	Nessus	Oracle Linux Local Security Checks	2021/7/23	2024/10/22	medium
151860	openSUSE 15 Security Update : containerd (openSUSE-SU-2021:2412-1)	Nessus	SuSE Local Security Checks	2021/7/21	2022/1/20	medium
159808	EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1445)	Nessus	Huawei Local Security Checks	2022/4/18	2022/5/6	medium
333780	Photon OS 5.0: Telegraf PHSA-2023-5.0-91-0041	Nessus	PhotonOS Local Security Checks	2026/8/10	2026/8/12	high
154638	SUSE SLES15: containerd / docker / docker-bash-completion / etc (SUSE-SU-2021:3506-1)	Nessus	SuSE Local Security Checks	2021/10/28	2026/6/26	high
159804	EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1424)	Nessus	Huawei Local Security Checks	2022/4/18	2022/5/6	medium
189846	GLSA-202401-31 : containerd: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	2024/1/31	2024/1/31	high
151874	SUSE SLES12 Security Update : containerd (SUSE-SU-2021:2413-1)	Nessus	SuSE Local Security Checks	2021/7/21	2026/6/25	medium
151966	Photon OS 2.0: Containerd PHSA-2021-2.0-0369	Nessus	PhotonOS Local Security Checks	2021/7/22	2024/7/23	medium
162441	EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)	Nessus	Huawei Local Security Checks	2022/6/22	2022/6/22	high
204388	Photon OS 5.0: Telegraf PHSA-2023-5.0-0041	Nessus	PhotonOS Local Security Checks	2024/7/24	2026/10/13	high

检测

插件搜索

medium

medium

medium

medium

medium

high

high

medium

high

medium

medium

high

high