遠端主機上安裝的 containerd 版本為早於 1.4.1-2 的版本。因此，它受到 ALAS2ECS-2023-030 公告中提及的一個弱點影響。

  - containerd 是符合業界標準的容器執行階段，可作為 Linux 和 Windows 的程序使用。
    在 containerd 1.3.9 和 1.4.3 之前版本中，containerd-shim API 會不當曝露於主機網路容器。shim 的 API 通訊端存取控制會驗證連線處理程序的有效 UID 是否為 0，但除此之外，並未限制對抽象 Unix 網域通訊端的存取。這可允許惡意容器在與 shim 相同的網路命名空間中執行，其有效 UID 為 0 但權限降低，進而導致新的處理程序以更高的權限執行。此弱點已在 containerd 1.3.9 和 1.4.3 中修正。使用者應在這些版本發佈後立即更新為這些版本。請注意，以舊版 containerd-shim 啟動的容器應停止並重新啟動，這是因為即使在升級後，執行中的容器仍將容易受到影響。如果您不允許未受信任的使用者在與 shim 相同的網路命名空間 (通常是主機網路命名空間，例如在 Kubernetes pod 中使用 docker 執行 --net= host 或 hostNetwork: true) 中啟動容器，且在有效 UID 為 0 的情況下執行，您就不會受到此問題影響。如果您執行的容器具有容易遭受攻擊的組態，可以在原則中新增與 deny unix addr = @ ** 類似的行，以拒絕透過 AppArmor 存取所有抽象通訊端。最佳做法是以減少的權限集，非零 UID 以及隔離的命名空間執行容器。containerd 維護人員強烈建議不要與主機共用命名空間。若減少用於容器的隔離機制組合，無論使用哪個容器執行階段來執行此容器，都必定會提高此容器的權限。(CVE-2020-15257)

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

偵測

Amazon Linux 2：containerd (ALASECS-2023-030)

medium Nessus Plugin ID 185923

版本 1.0