cURL 報告：

libcurl 會在使用後維持其最後幾個連線的集區，以針對應用程式進行簡單、方便且完全透明的連線重複使用。

當執行 NTLM 驗證的 HTTP 要求時，整個連線都會變成經過驗證，而不只是 HTTP 運作方式的特定 HTTP 要求。如此可使 NTLM 變得特殊，並因此在程式碼中需要特殊處理。若使用 NTLM，驗證連線後，不需要進一步驗證，直到連線關閉為止。

當執行交涉驗證的 HTTP 要求時，整個連線都可能會變成經過驗證，而不只是 HTTP 運作方式的特定 HTTP 要求，因為交涉可以在內部主要使用 NTLM。curl 並不遵循這一事實，但會假設此類要求也會根據要求進行驗證。

如 RFC 6265 中所述，libcurl 支援 HTTP 'Cookie'。連同每個個別 Cookie 一起，有數個不同的內容，但針對此弱點，我們會將焦點放在關聯的「路徑」元素上。
該元素提供有關 Cookie 對於指定主機上哪個路徑有效的資訊。

稱為 sanitize_cookie_path() 的內部 libcurl 函式 (可在遠端網站為其提供時或從檔案讀取時清理路徑元素)，並未正確驗證輸入。如果提供的路徑由單一雙引號組成，libcurl 會以索引 -1 索引新配置的記憶體區域，並為其指派零，進而損毀它不應該損毀的堆積記憶體。

libcurl 中有一個叫做 fix_hostname() 的私用函式，可從主機名稱中移除結尾的點 (若有)。在從要求 libcurl 做出反應之 URL 中擷取主機名稱之後，會呼叫此函式。

如果為 URL 提供零長度主機名稱，例如 'http://:80' 或僅 ':80'，fix_hostname() 會以 -1 位移索引主機名稱指標 (在其盲目地假設
非零長度時)，然後讀取及指派該位址。

偵測

FreeBSD：cURL -- 多個弱點 (6294f75f-03f2-11e5-aab1-d050996490d0)

medium Nessus Plugin ID 83842

找不到變更記錄