遠端 Azure Linux 3.0 主機上安裝的 cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer 版本比測試版舊。因此，此版本會受到 CVE-2024-45337 公告中提及的一個弱點影響。

  - 應用程式和程式庫誤用 connection.serverAuthenticate (透過回呼欄位 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)

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

偵測

Azure Linux 3.0 安全性更新cert-manager / cf-cli / docker-buildx / docker-compose / moby-compose / moby-engine / packer (CVE-2024-45337)

critical Nessus Plugin ID 215502

版本 1.1