遠端主機上安裝的 containerd 版本為早於 1.7.25-1 的版本。因此，它會受到 ALAS2ECS-2025-046 公告中提及的一個弱點影響。

    誤用 ServerConfig.PublicKeyCallback 回呼的應用程式和程式庫可能容易受到授權繞過影響。ServerConfig.PublicKeyCallback 的說明文件指出，對此函式的呼叫並不保證所提供的金鑰確實用於驗證。具體而言，SSH 通訊協定允許用戶端在證明對應私密金鑰的控制權之前，查詢是否可接受公開金鑰。PublicKeyCallback 受到呼叫時可能接收到多組金鑰，然而其提供順序無法用於推斷用戶端最終成功驗證的公鑰為何 (若有)。
    部分應用程式會儲存傳遞至 PublicKeyCallback 的金鑰 (或其衍生資訊)，並在連線建立後據此做出安全性相關決策，因此可能會做出錯誤的假設。例如，攻擊者可能傳送公開金鑰 A 和 B，然後使用 A 進行驗證。
    PublicKeyCallback 只會被呼叫兩次，依序使用 A 和 B。接著易受攻擊的應用程式可能會根據金鑰 B 做出授權決策，即使攻擊者實際上無法控制其私密金鑰。由於此 API 遭到廣泛誤用，因此 golang.org/x/cry...@v0.31.0 強制套用下列屬性作為局部緩解措施: 一旦透過公開金鑰成功驗證，則以最後一組傳遞給 ServerConfig.PublicKeyCallback 的公開金鑰為實際驗證連線的金鑰。現在會視需要以相同的金鑰多次呼叫 PublicKeyCallback。請注意，如果連線隨後使用不同的方法 (例如 PasswordCallback、KeyboardInteractiveCallback 或 NoClientAuth) 進行驗證，則用戶端可能仍然無法控制傳遞至 PublicKeyCallback 的最後一組金鑰。使用者應透過各種驗證回呼所傳回的「權限」值之「延伸模組」欄位，記錄與驗證嘗試相關的資料，而非參照外部狀態。建立連線後，即可透過 ServerConn.Permissions 欄位檢索與成功驗證嘗試相應的狀態資訊。請注意，某些第三方程式庫會在多次驗證嘗試中重複使用權限類型。有鑑於此類誤用，這些第三方程式庫的使用者應參閱相關專案以學習其正確用法。(CVE-2024-45337)

Tenable 已直接從所測試產品的安全公告擷取前置描述區塊。

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

偵測

Amazon Linux 2 : containerd (ALASECS-2025-046)

critical Nessus Plugin ID 214922

版本 1.1