在 curl (一種使用 URL 語法傳輸資料的命令行工具和一個易於使用的用戶端 URL 傳輸程式庫) 中發現數個弱點。

CVE-2020-8284

當 curl 執行被動式 FTP 傳輸時，它會先嘗試 EPSV 命令，如果該命令不受支援，則會回退為使用 PASV。
被動模式是 curl 預設使用的模式。伺服器對 PASV 命令的回應包含用戶端可以重新連線的 (IPv4) 位址和連接埠號碼，以便執行實際的資料傳輸。這就是 FTP 通訊協定的工作方式。惡意伺服器可利用 PASV 回應誘騙 curl 連回指定的 IP 位址和連接埠，這樣有可能會讓 curl 擷取本應為私人且未洩漏之服務的相關資訊，例如執行連接埠掃描和服務標題擷取。

回應的 IP 位址部分現在預設為忽略，方法是將 CURLOPT_FTP_SKIP_PASV_IP 預設為 1L，而不是之前的 0L。這有一個次要缺陷，即當伺服器確實需要用戶端連線回與控制項連線使用的 IP 位址不同的 IP 位址，且 CURLOPT_FTP_SKIP_PASV_IP 可設為 0L 時，一小部分使用案例可能會中斷。命令行工具也是如此，之後可能需要

--no-ftp-skip-pasv-ip 設定，以防止 curl 忽略伺服器回應中的位址。

CVE-2020-8285

libcurl 提供萬用字元比對功能，允許回呼 (以 CURLOPT_CHUNK_BGN_FUNCTION 設定) 在 libcurl 反覆使用所有可用項目的清單時，將有關如何處理目錄中特定項目的資訊傳回 libcurl。若此回呼傳回 CURL_CHUNK_BGN_FUNC_SKIP 以告知 libcurl 不處理該檔案，libcurl 中的內部函式會以遞回方式呼叫本身，以處理下一個目錄項目。如果有足夠數量的檔案項目，且回呼傳回「skip」的次數足夠多，則 libcurl 會耗盡堆疊空間。當然，確切的數量因平台、編譯器和其他環境因素而異。遠端目錄的內容並未保留在堆疊上，因此攻擊者似乎難以確切控制覆寫堆疊的資料，但這仍然是一個拒絕服務向量，因爲控制使用 libcurl 的應用程式在這些前提下配合運作的伺服器的惡意使用者可觸發當機。

此內部函式被改寫為使用一般迴圈，而非遞回方法。這樣，無論略過多少檔案，堆疊使用量都將保持不變。

CVE-2020-8286

libcurl 透過 CURLOPT_SSL_VERIFYSTATUS 選項提供「OCSP stapling」。設定後，libcurl 會驗證伺服器在 TLS 交握過程中所使用的 OCSP 回應。如果回應有問題，它就會中止 TLS 交涉。使用此 curl 工具，可透過 --cert-status 啟用相同的功能。作為 OCSP 回應驗證的一部分，用戶端應驗證回應是否確實針對正確的憑證發出。在構建或告知使用 OpenSSL 作為 TLS 後端時，libcurl 未執行此步驟。
攻擊者 (可能已入侵 TLS 伺服器) 可利用此弱點提供看似正常的偽造 OCSP 回應，而非真正的回應，就像原始憑證實際上已被撤銷一樣。

OCSP 回應檢查器函式現在也會驗證憑證 ID 是否正確。

針對 Debian 9 Stretch，已在 7.52.1-5+deb9u13 版本中修正這些問題。

建議您升級 curl 套件。

如需有關 curl 安全性狀態的詳細資訊，請參閱其安全追蹤頁面： https://security-tracker.debian.org/tracker/curl

注意：Tenable Network Security 已直接從 DLA 安全性公告擷取前置描述區塊。Tenable 已盡量在不造成其他問題的前提下，嘗試自動清理並將其格式化。

偵測

Debian DLA-2500-1：curl 安全性更新

high Nessus Plugin ID 144497

版本 1.7