遠端主機會受到 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 並未測試這些問題，而是僅依據應用程式自我報告的版本號碼作出判斷。

偵測

GLSA-202401-31：containerd：多個弱點

high Nessus Plugin ID 189846

版本 1.0