GLSA-202310-12: curl：多個弱點

critical Nessus Plugin ID 182879

語系：

說明

遠端主機受到 GLSA-202310-12 中所述的弱點影響 (curl：多個弱點)

- curl <7.87.0 HSTS 檢查中存在弱點，攻擊者可繞過檢查以誘騙其繼續使用 HTTP。
若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。但是，如果給定 URL 中的主機名稱首先使用 IDN 轉換過程中被取代為 ASCII 對應項的 IDN 字元，則可能繞過 HSTS 機制。如同使用 UTF-8 U+3002 (IDEOGRAPHIC FULL STOP) 字元，而非一般的 ASCII 句號 (U+002E)「.」。然後在後續要求中，它不會偵測 HSTS 狀態並進行純文字傳輸。因為它會儲存以 IDN 編碼的資訊，但尋找以 IDN 解碼的資訊。(CVE-2022-43551)

- 低於 7.87.0 版的 curl 中存在一個釋放後使用弱點。可以要求 Curl 透過 HTTP Proxy 為其支援的所有通訊協定*建立通道*。HTTP Proxy 可以 (而且經常) 拒絕此類通道作業。
當特定通訊協定 SMB 或 TELNET 被拒絕時，curl 會在其傳輸關閉程式碼路徑中使用堆積配置結構。(CVE-2022-43552)

- 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸漏洞，當連續請求多個 URL 時，該漏洞可能導致 HSTS 功能失敗。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，在相同命令行上完成後，後續傳輸會意外忽略此 HSTS 機制，因為狀態將無法正確執行。 (CVE-2023-23914)

- 早於 v7.88.0 的 curl 中存在敏感資訊純文字傳輸漏洞，當並行請求多個 URL 時，該漏洞可能導致 HSTS 功能行為不正確。若使用 HSTS 支援，即使已在 URL 中提供 HTTP，仍可指示 curl 使用 HTTPS，而不使用不安全的純文字 HTTP 步驟。然而，當並行完成多個傳輸時，此 HSTS 機制會意外失敗，因為 HSTS 快取檔案會被最近完成的傳輸覆寫。之後對舊版主機名稱的純 HTTP 傳輸*不會*正確升級至 HSTS。
(CVE-2023-23915)

- v7.88.0 之前版本的 curl 基於鏈結式 HTTP 壓縮演算法，存在資源配置無限制或無節流弱點，這表示伺服器回應可被壓縮多次，並且可能使用不同的演算法。此解壓縮鏈中可接受的連結數設有上限，但該上限是依標頭實作的，惡意伺服器可利用許多標頭來插入幾乎不受限制的壓縮步驟數。使用此類解壓縮鏈可導致 malloc 炸彈，進而使 curl 最終花費大量已配置的堆積記憶體，或嘗試並傳回記憶體不足錯誤。(CVE-2023-23916)

- 在使用 TELNET 通訊協定進行通訊期間，curl 8.0 之前版本存在輸入驗證弱點，攻擊者可在伺服器交涉期間傳遞惡意特製的使用者名稱和 telnet 選項。
由於缺少適當的輸入清除，攻擊者可在沒有應用程式意圖的情況下傳送內容或執行選項交涉。如果應用程式允許使用者輸入，攻擊者就可以利用此弱點，在系統上執行任意程式碼。(CVE-2023-27533)

- curl 8.0.0 之前版本的 SFTP 實作中存在路徑遊走弱點。波浪號 (~) 除了預定用作指示使用者主目錄之相對路徑的第一個元素外，在第一個路徑元素中作為前置詞使用時，會被錯誤地取代。攻擊者可利用此弱點繞過篩選，或在以特定使用者的身分存取伺服器時，透過僞造類似 /~2/foo 的路徑來執行任意程式碼。(CVE-2023-27534)

- libcurl 8.0.0 之前版本的 FTP 連線重複使用功能中存在驗證繞過弱點，可導致在後續傳輸期間使用錯誤的憑證。如果先前建立的連線符合目前的設定，則會保留在連線集區中供重複使用。但是，某些 FTP 設定 (如 CURLOPT_FTP_ACCOUNT、CURLOPT_FTP_ALTERNATIVE_TO_USER、CURLOPT_FTP_SSL_CCC 和 CURLOPT_USE_SSL) 並未包含在組態相符檢查中，從而導致它們太容易相符。這可引致 libcurl 在執行傳輸時使用錯誤的憑證，進而可能允許使用者在未經授權的情況下存取敏感資訊。(CVE-2023-27535)

- libcurl 8.0.0 之前版本的連線重複使用功能中存在驗證繞過弱點，因為無法檢查 CURLOPT_GSSAPI_DELEGATION 選項中的變更，所以可使用錯誤的使用者權限重複使用之前建立的連線。此弱點會影響 krb5/kerberos/negotiate/GSSAPI 傳輸，並可能導致使用者在未經授權的情況下存取敏感資訊。如果 CURLOPT_GSSAPI_DELEGATION 選項已變更，則最安全的選項是不重複使用連線。(CVE-2023-27536)

- libcurl 8.0.0 之前版本在不同的處理序之間共用 HSTS 資料時，會產生重複釋放弱點。
引入此共用功能時未考慮跨獨立執行緒的共用，但說明文件中並未指出此事實。由於缺少 mutex 或執行緒鎖定，共用相同 HSTS 資料的兩個執行緒可能會導致重複釋放或釋放後使用。(CVE-2023-27537)

- 早於 v8.0.0 版的 libcurl 中存在驗證繞過弱點。儘管已修改 SSH 選項，但程式仍會重複使用先前建立的 SSH 連線，此連線本應被阻止重複使用。如果組態相符，libcurl 會維護先前使用的連線集區，以便在後續傳輸中重複使用這些連線。不過，組態檢查中忽略了兩個 SSH 設定，這使得它們可以輕鬆比對，進而可能導致重複使用不當連線。(CVE-2023-27538)

- 在低於 v8.1.0 的 curl 中存在釋放後使用弱點，體現在 libcurl 使用 SHA 256 雜湊驗證 SSH 伺服器公開金鑰中。此檢查失敗時，libcurl 會在傳回包含 (現已釋放) 雜湊的錯誤訊息之前，釋放記憶體以供指紋識別功能使用。此瑕疵有將敏感堆積型資料插入錯誤訊息中的風險，該訊息可能會顯示給使用者，或可能會遭到洩漏和洩漏。(CVE-2023-28319)

- 在低於 v8.1.0 的 curl 中存在拒絕服務弱點，體現在 libcurl 提供了多個不同的後端來解析構建時選擇的主機名稱中。如果構建為使用同步解析器，則允許名稱解析為使用「alarm()」和「siglongjmp()」的緩慢作業逾時。執行此操作時，libcurl 會使用未受 mutex 保護的全域緩衝區，因此多執行緒應用程式可能會損毀或發生其他不當行為。(CVE-2023-28320)

- curl v8.1.0 之前版本中存在憑證驗證不當弱點，它支援比對 TLS 伺服器憑證中做為主體別名列出的萬用字元符號。curl 可以被構建為針對 TLS 使用自己的名稱比對函式，而不是 TLS 庫提供的函式。此私人萬用字元比對函式會錯誤比對 IDN (國際網域名稱) 主機，並因此接受本應不相符的符號。IDN 主機名稱會先轉換為 puny 程式碼，然後再用於憑證檢查。Puny 編碼名稱一律以「xn--」開頭，且不應允許進行符號比對，但 curl 中的萬用字元檢查仍可檢查「x*」，即使 IDN 名稱很可能不包含任何與「x」類似的符號，仍會被視為與「x*」一致。(CVE-2023-28321)

- curl v8.1.0 之前版本在進行 HTTP(S) 傳輸時，如果之前曾使用相同的控點發出使用讀取回呼 (「CURLOPT_READFUNCTION」) 的「PUT」要求，則 libcurl 可能會錯誤地使用此回呼來要求要傳送的資料，即使已經設定「CURLOPT_POSTFIELDS」選項亦如此。此缺陷可能會使應用程式意外產生錯誤行為，並在第二次傳輸中傳送錯誤資料或使用釋放後的記憶體，或發生類似情況。從 PUT 變更為 POST 時 (預期如此)，重複使用的控點邏輯中存在此問題。(CVE-2023-28322)

- 當 curl 擷取 HTTP 回應時，會儲存傳入的標頭，以便日後透過 libcurl 標頭 API 進行存取。不過，curl 並未限制其可在回應中接受的標頭數量或大小，進而允許惡意伺服器串流無限系列的標頭，並最終造成 curl 耗盡堆積記憶體。(CVE-2023-38039)

- CVE-2023-38545 是 libcurl 和 curl 之 SOCKS5 proxy 交握中的一個堆積型緩衝區溢位弱點。當為 curl 指定要傳送至長度超過 255 位元組的 SOCKS5 proxy 的主機名稱時，它會切換至本機名稱解析，以便在將位址傳送至 SOCKS5 proxy 之前先解析該位址。不過，由於 2020 年引入的一個錯誤，此本機名稱解析可能會因為 SOCKS5 交握緩慢而失敗，進而造成 curl 將長度大於 255 位元組的主機名稱傳遞至目標緩衝區，從而導致堆積溢位。 CVE-2023-38545 的公告包含惡意 HTTPS 伺服器重新導向至特製 URL 的惡意利用情形範例。盡快大家認為攻擊者似乎需要影響 SOCKS5 交握的緩慢速度，但該公告指出伺服器延遲可能慢到足以觸發此錯誤。(CVE-2023-38545)

- 如需詳細資料，請檢閱提及的 CVE 識別碼。請注意，遠端程式碼執行的風險僅限於 SOCKS 使用。(CVE-2023-38546)

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