遠端主機上安裝的 containerd 版本為早於 1.6.19-1 的版本。因此，會受到 ALAS2NITRO-ENCLAVES-2023-023 公告中所提及的多個弱點影響。

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

  - containerd 是一種開放原始碼的容器執行階段。在 1.6.18 之前版本和 1.5.18 之前版本中，匯入 OCI 鏡像時，對於特定檔案的讀取位元組數沒有任何限制。在未套用限制的情況下，包含大型檔案的惡意特製鏡像可造成程式拒絕服務。此錯誤已在 containerd 1.6.18 和 1.5.18 中修正。使用者應更新至這些版本以解決此問題。因應措施是確保只使用受信任的鏡像，而且只有受信任的使用者才有權匯入鏡像。
    (CVE-2023-25153)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

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

遠端主機會受到 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.6.19-1 的版本。因此，它受到 ALAS2DOCKER-2023-023 公告中所提及的多個弱點影響。

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

  - containerd 是一種開放原始碼的容器執行階段。在 1.6.18 之前版本和 1.5.18 之前版本中，匯入 OCI 鏡像時，對於特定檔案的讀取位元組數沒有任何限制。在未套用限制的情況下，包含大型檔案的惡意特製鏡像可造成程式拒絕服務。此錯誤已在 containerd 1.6.18 和 1.5.18 中修正。使用者應更新至這些版本以解決此問題。因應措施是確保只使用受信任的鏡像，而且只有受信任的使用者才有權匯入鏡像。
    (CVE-2023-25153)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

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

因此，它受到 ALAS2023-2023-156 公告中所提及的多個弱點影響。

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

  - containerd 是一種開放原始碼的容器執行階段。在 1.6.18 之前版本和 1.5.18 之前版本中，匯入 OCI 鏡像時，對於特定檔案的讀取位元組數沒有任何限制。在未套用限制的情況下，包含大型檔案的惡意特製鏡像可造成程式拒絕服務。此錯誤已在 containerd 1.6.18 和 1.5.18 中修正。使用者應更新至這些版本以解決此問題。因應措施是確保只使用受信任的鏡像，而且只有受信任的使用者才有權匯入鏡像。
    (CVE-2023-25153)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

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

遠端主機上安裝的 containerd 版本為早於 1.6.19-1 的版本。因此，它受到 ALAS2ECS-2023-002 公告中所提及的多個弱點影響。

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

  - containerd 是一種開放原始碼的容器執行階段。在 1.6.18 之前版本和 1.5.18 之前版本中，匯入 OCI 鏡像時，對於特定檔案的讀取位元組數沒有任何限制。在未套用限制的情況下，包含大型檔案的惡意特製鏡像可造成程式拒絕服務。此錯誤已在 containerd 1.6.18 和 1.5.18 中修正。使用者應更新至這些版本以解決此問題。因應措施是確保只使用受信任的鏡像，而且只有受信任的使用者才有權匯入鏡像。
    (CVE-2023-25153)

  - containerd 是一種開放原始碼的容器執行階段。在 containerd 1.6.18 之前版本和 1.5.18 之前版本中發現一個錯誤，容器內未正確設定附加群組。如果攻擊者擁有容器的直接存取權並操控其附加群組存取權，則在某些情況下，他們可能能夠使用附加群組存取權繞過主要群組限制，進而可能獲得敏感資訊的存取權，或能夠在此容器中執行程式碼。使用 containerd 用戶端程式庫的下游應用程式也可能受到影響。此錯誤已在 containerd v1.6.18 和 v.1.5.18 中修正。使用者應更新至這些版本，並且重新建立容易以解決此問題。
    使用者若依賴使用 containerd 用戶端程式庫的下游應用程式，應檢查此應用程式是否有單獨的公告和指示。因應措施是確保不使用 `USER $USERNAME` Dockerfile 指令，而是將容器入口點設定為類似 `ENTRYPOINT [su, -, user]` 的值，以允許 `su` 正確設定附加群組。(CVE-2023-25173)

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

遠端 Ubuntu 18.04 LTS/20.04 LTS/22.04 LTS/22.10 主機上安裝的套件受到 USN-5776-1 公告中所提及的多個弱點影響。

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

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

  - imgcrypt 程式庫為 containerd 提供 API 延伸模組，以支援加密的容器影像，並實作 ctd-decoder 命令行工具，供 containerd 用來解密加密的容器影像。
    imgcrypt 函式「CheckAuthorization」應該檢查目前使用的內容是否有權存取加密的影像，並防止使用者執行先前在相同系統上解密的影像。在 1.1.4之前的版本中，使用具有 ManifestList 的影像，且本機主機的架構不是 ManifestList 中的第一個架構時，會導致失敗。僅測試了清單中的第一個架構，由於該架構的層無法在主機架構上執行，因此該框架無法本機使用。因此，對於不可用的層的判斷是，預期在稍後會因為層不可用而發生影像執行失敗的情況下，可以執行影像。
    但是，如果該影像之前已解密，則此允許影像執行的判定使得 ManifestList 中的其他架構無需提供金鑰即可執行該影像。修補程式已套用至 imgcrypt 1.1.4 版。因應措施可能包括針對每個遠端使用者使用不同的命名空間。
    (CVE-2022-24778)

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

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

ID	名稱	產品	系列	已發布	已更新	嚴重性
173937	Amazon Linux 2：containerd (ALASNITRO-ENCLAVES-2023-023)	Nessus	Amazon Linux Local Security Checks	2023/4/6	2023/10/6	high
189846	GLSA-202401-31：containerd：多個弱點	Nessus	Gentoo Local Security Checks	2024/1/31	2024/1/31	high
173939	Amazon Linux 2：containerd (ALASDOCKER-2023-023)	Nessus	Amazon Linux Local Security Checks	2023/4/6	2023/10/6	high
173839	Amazon Linux 2023：containerd、containerd-stress (ALAS2023-2023-156)	Nessus	Amazon Linux Local Security Checks	2023/4/4	2023/10/6	high
178287	Amazon Linux 2：containerd (ALASECS-2023-002)	Nessus	Amazon Linux Local Security Checks	2023/7/14	2023/10/6	high
168653	Ubuntu 18.04 LTS / 20.04 LTS / 22.04 LTS：containerd 弱點 (USN-5776-1)	Nessus	Ubuntu Local Security Checks	2022/12/13	2023/10/16	high

偵測

搜尋 Plugin

high

high

high

high

high

high