遠端主機會受到 GLSA-202401-31 中所述的弱點影響 (containerd：多個弱點)

  - containerd 是一種容器執行階段。在 1.4.8 和 1.5.4 之前的 containerd 版本中發現一個錯誤，在這些版本中，提取和擷取特製的容器映像可變更主機檔案系統中現有檔案的 Unix 檔案權限。變更檔案權限可能會拒絕預期檔案擁有者的存取權、放寬其他使用者的存取權，或設定延伸位元，例如 setuid、setgid 和 sticky。此錯誤不會直接允許在沒有其他合作處理程序的情況下讀取、修改或執行檔案。此錯誤已在 containerd 1.5.4 和 1.4.8 中修正。作為因應措施，請確保使用者僅從受信任的來源提取影像。Linux 安全性模組 (LSM)(如 SELinux 和 AppArmor) 可透過防止 containerd 與特定檔案互動的原則和設定檔，限制可能受到此錯誤影響的檔案。(CVE-2021-32760)

  - containerd 是一個開放原始碼的容器執行階段，著重提供簡單性、穩定性和可攜性。
    在 containerd 中發現一個錯誤，即容器 root 目錄和部分外掛程式存在未充分限制權限的問題，進而允許無權限的 Linux 使用者遍歷目錄內容並執行程式。當容器包含具有延伸權限位元的可執行程式 (例如 setuid) 時，無權限的 Linux 使用者可能會發現並執行這些程式。當主機上無權限的 Linux 使用者 UID 與容器內的檔案擁有者或群組發生衝突時，主機上的無權限 Linux 使用者有可能發現、讀取和修改這些檔案。此弱點已在 containerd 1.4.11 和 1.5.7 中修正。使用者應在這些版本發佈時及時更新，並可重新啟動容器或更新目錄權限，以減輕該弱點帶來的影響。針對無法更新的使用者，應限制僅讓受信任的使用者存取主機。更新容器套件目錄的目錄權限。(CVE-2021-41103)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 的 CRI 實作中發現一個錯誤，其中使用者可耗盡主機上的記憶體。在 CRI 串流伺服器中，如果要求 TTY，則會啟動一個 goroutine 來處理終端機調整大小事件。如果使用者的處理程序因為命令錯誤等原因而無法啟動，則 goroutine 將在沒有接收器的情況下等待傳送，進而導致記憶體洩漏。
    Kubernetes 和 crictl 都可以設定為使用 containerd 的 CRI 實作，串流伺服器用於處理容器 IO。此錯誤已在 containerd 1.6.12 和 1.5.16 中修正。使用者應更新至這些版本以解決此問題。無法升級的使用者應確保僅使用受信任的影像和命令，且只有受信任的使用者才有權在執行中的容器中執行命令。(CVE-2022-23471)

  - containerd 是一個容器執行階段，可作為 Linux 和 Windows 的程序使用。在 containerd 1.6.1、1.5.10 和 1.14.12 更早版本中發現一個錯誤，其中在 Linux 上透過 containerd 的 CRI 實作啟動的容器可以使用特製的映像組態，存取主機上任意文件和目錄的唯讀複本。這可能會繞過容器設定的任何強制執行原則 (包括 Kubernetes Pod 安全性原則)，並洩漏潛在的敏感資訊。
    Kubernetes 和 crictl 都可以設定為使用 containerd 的 CRI 實作。此錯誤已在 containerd 1.6.1、1.5.10 和 1.4.12 版本中修正。使用者應更新至這些版本以解決此問題。
    (CVE-2022-23648)

  - Moby 是 Docker 建立的開放原始碼專案，可用於啟用並加速軟體容器化。在 20.10.14 版之前的 Moby (Docker Engine) 中發現一個錯誤，其中，容器以非空白的可繼承 Linux 處理程序功能啟動，進而建立非典型 Linux 環境，並使具有可繼承檔案功能的程式在執行期間將這些功能提升至允許的集合`execve(2)`。通常，當可執行程式已指定允許的檔案功能時，無權限的使用者和處理程序可執行這些程式並取得邊界集內的指定檔案功能。由於此錯誤，包含具有可繼承檔案功能的可執行程式的容器允許無權限的使用者和處理程序額外取得這些可繼承檔案功能，直到容器的邊界集為止。使用 Linux 使用者和群組在容器內執行權限分隔的容器會受到最直接的影響。這個錯誤不會影響容器安全沙箱，因為可繼承集包含的功能絕不會超過容器邊界集中包含的功能。此錯誤已在 Moby (Docker Engine)  20.10.14 中修正。您應終止、刪除並重新建立執行中的容器，以便重設可繼承功能。這項修正變更了 Moby (Docker Engine) 行為，使得容器在啟動時建立更典型的 Linux 環境。要想解決這個問題，可以透過修改容器入口點使用 `capsh(1)` 等公用程式，以便在主要處理程序啟動之前中斷可繼承功能。(CVE-2022-24769)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 的 CRI 實作中發現一個錯誤，其中容器內的程式可造成 containerd 程序在「ExecSync」API 叫用期間無限制地消耗記憶體。從而導致 containerd 耗盡電腦上的所有可用記憶體，拒絕為其他合法工作負載提供服務。Kubernetes 和 crictl 都可以設定為使用 containerd 的 CRI 實作；執行探查或透過 exec 設施執行處理程序時，可使用 「ExecSync」。此錯誤已在 containerd 1.6.6 和 1.5.13 中修正。使用者應更新至這些版本以解決此問題。無法升級的使用者應確保只使用受信任的影像和命令。(CVE-2022-31030)

請注意，Nessus 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

远程主机上安装的 containerd 版本低于 1.4.13-2。因此，该应用程序受到 ALAS2-2022-1775 公告中提及的漏洞的影响。

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby（Docker Engine）行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

远程主机上安装的 containerd 版本低于 1.4.13-2.1。远程主机上安装的 docker 版本低于 20.10.13-2.1。因此，该应用程序受到 ALAS-2022-1582 公告中提及的漏洞的影响。

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

因此，该应用程序受到 ALAS2022-2022-054 公告中提及的漏洞的影响。

  - Moby 是 Docker 创建的开源项目，用于实现并加快软件容器化。在低于 20.10.14 版本的 Moby (Docker Engine) 中发现一个错误，其中容器以非空、可继承的 Linux 进程功能启动，从而创建非典型 Linux 环境，并使具有可继承文件功能的程序在 `execve(2)` 期间将这些功能提升至允许的集。通常，当可执行程序已指定允许的文件功能时，无特权用户和进程就可以执行这些程序并获得符合边界集规定的指定文件功能。由于存在这一错误，包含具有可继承文件功能的可执行程序的容器允许无特权用户和进程额外获得此类符合容器边界集规定的可继承文件功能。使用 Linux 用户和群组在容器内执行特权分离的容器受此错误的影响最大。此错误不影响容器安全沙盒，因为可继承集包含的功能绝不会多于容器边界集中包含的功能。此错误已在 Moby (Docker Engine) 中修复 20.10.14。您应当停止、删除并重新创建正在运行的容器，以便重置可继承功能。此补丁更改了 Moby (Docker Engine) 行为，以便在启动容器时创建更典型的 Linux 环境。有一种解决办法是，修改容器的入口点，以使用“capsh(1)”等实用工具，在主进程启动之前终止可继承功能。(CVE-2022-24769)

请注意，Nessus 尚未测试此问题，而是只依据应用程序自我报告的版本号进行判断。

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.

The version of containerd installed on the remote host is prior to 1.4.13-2. The version of docker installed on the remote host is prior to 20.10.13-2. It is, therefore, affected by a vulnerability as referenced in the ALAS2DOCKER-2022-018 advisory.

  - 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 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 package installed, the EulerOS installation on the remote host is affected by the following vulnerabilities :

  - 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 version of containerd installed on the remote host is prior to 1.4.13-2. It is, therefore, affected by a vulnerability as referenced in the ALAS2ECS-2023-023 advisory.

  - 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 Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

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

  - The x/crypto/ssh package before 0.0.0-20211202192323-5770296d904e of golang.org/x/crypto allows an     attacker to panic an SSH server. (CVE-2021-43565)

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

  - The golang.org/x/crypto/ssh package before 0.0.0-20220314234659-1baeb1ce4c0b for Go allows an attacker to     crash a server in certain circumstances involving AddHostKey. (CVE-2022-27191)

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

The version of containerd installed on the remote host is prior to 1.4.13-3. The version of docker installed on the remote host is prior to 20.10.13-2. The version of ecs-init installed on the remote host is prior to 1.61.1-1. The version of runc installed on the remote host is prior to 1.0.3-3. It is, therefore, affected by a vulnerability as referenced in the ALAS2ECS-2022-001 advisory.

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

Note that Nessus has not tested for this issue 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.

ID	Name	Product	Family	Published	Updated	Severity
189846	GLSA-202401-31：containerd：多個弱點	Nessus	Gentoo Local Security Checks	1/31/2024	1/31/2024	high
160267	Amazon Linux 2：containerd (ALAS-2022-1775)	Nessus	Amazon Linux Local Security Checks	4/27/2022	4/27/2022	medium
160334	Amazon Linux AMI：containerd、docker (ALAS-2022-1582)	Nessus	Amazon Linux Local Security Checks	4/29/2022	4/29/2022	medium
164726	Amazon Linux 2022：(ALAS2022-2022-054)	Nessus	Amazon Linux Local Security Checks	9/6/2022	9/6/2022	medium
162441	EulerOS 2.0 SP8 : docker-engine (EulerOS-SA-2022-1926)	Nessus	Huawei Local Security Checks	6/22/2022	6/22/2022	high
160412	Amazon Linux 2 : docker, containerd (ALASDOCKER-2022-018)	Nessus	Amazon Linux Local Security Checks	5/2/2022	5/2/2022	medium
162917	EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1963)	Nessus	Huawei Local Security Checks	7/8/2022	7/8/2022	medium
162920	EulerOS 2.0 SP9 : docker-engine (EulerOS-SA-2022-1993)	Nessus	Huawei Local Security Checks	7/8/2022	7/8/2022	medium
163537	EulerOS 2.0 SP10 : docker-engine (EulerOS-SA-2022-2154)	Nessus	Huawei Local Security Checks	7/29/2022	7/29/2022	medium
185921	Amazon Linux 2 : containerd (ALASECS-2023-023)	Nessus	Amazon Linux Local Security Checks	11/16/2023	11/16/2023	medium
161237	SUSE SLES15 Security Update : containerd, docker (SUSE-SU-2022:1689-1)	Nessus	SuSE Local Security Checks	5/17/2022	7/13/2023	high
178301	Amazon Linux 2 : ecs-init, docker, containerd, runc (ALASECS-2022-001)	Nessus	Amazon Linux Local Security Checks	7/14/2023	10/11/2023	high
189846	GLSA-202401-31 : containerd: Multiple Vulnerabilities	Nessus	Gentoo Local Security Checks	1/31/2024	1/31/2024	high

Detections

Analytics

Plugins Search

high

medium

medium

medium

high

medium

medium

medium

medium

medium

high

high

high