cURL 報告：

重複使用連線時，libcurl 可能會錯誤傳送 HTTP 認證。

libcurl 允許應用程式使用 HTTP 基本驗證 (例如：CURLOPT_USERPWD)，為即將進行的傳輸設定認證。名稱和密碼。正如所有其他 libcurl 選項，認證將設為黏著並與「控制碼」保持關聯，直到有任何事情改變現狀為止。

此外，libcurl 會提供 curl_easy_reset() 函式，其可就所有可設定的選項，將控制碼重設回其原始狀態。重設當然也會清除認證。重設通常可用於清除控制碼，並為其準備可能不相關的新傳輸。

為因應系統要求第二次傳輸提供使目前連線保持使用中的主機名稱，在此類控制碼中，libcurl 還會儲存一組先前的連線。

受到此瑕疵的影響，即使在重設後使用控制碼，只要對同一個主機名稱提出要求且先前曾存取該連線，就會使 libcurl 在後續的要求中意外使用這些認證。

例如，第一次先向網站的某區段要求受到密碼保護的資源，然後再從網站上其他完全不同的區段，在未經驗證的情況下，對公開資源提出第二次要求。因而此瑕疵會在第二次要求中不慎洩漏認證。

libcurl 可能會遭惡意 SMB 伺服器誘騙，而寄出非預定的資料。

在 libcurl 內用於處理 SMB 通訊協定 (smb_request_state()) 的狀態機器函式中，透過網路傳送抵達的資料有兩個長度和位移值會遭到擷取，而這些值隨後可用來推斷應該回傳的資料範圍。

所使用且受到信任的值未經邊界檢查，而已視為有效。此可允許精密特製的套件誘騙 libcurl 回應並傳送非預定的資料。或者，在這些值造成 libcurl 存取無效記憶體時直接當機。

偵測

FreeBSD : cURL -- 多個弱點 (2438d4af-1538-11e5-a106-3c970e169bc2)

medium Nessus Plugin ID 84254

找不到變更記錄