cURL reports :

libcurl keeps a pool of its last few connections around after use to facilitate easy, convenient, and completely transparent connection re-use for applications.

When doing HTTP requests NTLM authenticated, the entire connection becomes authenticated and not just the specific HTTP request which is otherwise how HTTP works. This makes NTLM special and a subject for special treatment in the code. With NTLM, once the connection is authenticated, no further authentication is necessary until the connection gets closed.

When doing HTTP requests Negotiate authenticated, the entire connection may become authenticated and not just the specific HTTP request which is otherwise how HTTP works, as Negotiate can basically use NTLM under the hood. curl was not adhering to this fact but would assume that such requests would also be authenticated per request.

libcurl supports HTTP 'cookies' as documented in RFC 6265. Together with each individual cookie there are several different properties, but for this vulnerability we focus on the associated 'path' element.
It tells information about for which path on a given host the cookies is valid.

The internal libcurl function called sanitize_cookie_path() that cleans up the path element as given to it from a remote site or when read from a file, did not properly validate the input. If given a path that consisted of a single double-quote, libcurl would index a newly allocated memory area with index -1 and assign a zero to it, thus destroying heap memory it wasn't supposed to.

There is a private function in libcurl called fix_hostname() that removes a trailing dot from the host name if there is one. The function is called after the host name has been extracted from the URL libcurl has been told to act on.

If a URL is given with a zero-length host name, like in 'http://:80' or just ':80', fix_hostname() will index the host name pointer with a
-1 offset (as it blindly assumes a non-zero length) and both read and assign that address.

cURL の報告：

libcurl は、アプリケーションに対して簡単かつ便利で完全に透明な接続の再利用を容易にするために、最近使用したいくつかの接続のプールを維持します。

NTLM 認証のための HTTP リクエストを行う際、特定の HTTP リクエストのみではなく、接続全体が認証されます。本来では、HTTP はそのように動作します。これが、NTLM が特種で、コード内で特別な扱いを行う対象となっている理由です。NTLM を使用して、接続が認証されると、接続が切断されるまで、これ以上の認証は不要になります。

Negotiate の認証のための HTTP リクエストを行う際、特定の HTTP リクエストのみではなく、接続全体が認証されます。本来では、HTTP はこのように動作します。これは、Negotiate が基本的にフード下で NTLM を使用できるためです。curl は、この事実を遵守しませんが、そのようなリクエストは各リクエストごとに認証されるものとして想定します。

libcurl は、RFC 6265 で文書化されている HTTP「クッキー」をサポートしています。個々のクッキーとともに、複数の個別のプロパティがありますが、この脆弱性に対しては、関連した「パス」要素に焦点を合わせています。
クッキーが有効である、与えられたホスト上のパスについての情報を示します。

リモートサイトからパス要素が与えられるとき、またはファイルから読み込まれる際に、パス要素をクリーンアップする sanitize_cookie_path() という内部 libcurl 関数が、入力を適切に検証していませんでした。単一の二重引用符からなるパスが与えられた場合、libcurl は新しく割り当てらたメモリ領域を index -1 でインデックス化し、それにゼロを割り当てます。それにより、予期しないヒープメモリを破壊します。

末尾のドットが存在する場合にホスト名からこのドットを削除する、fix_hostname() というプライベート関数があります。この関数は、ホスト名が URL から抽出され、libcurl が反応するように命令された後で呼び出されます。

URL が「http://:80」または「:80」のようなゼロレングスのホスト名で与えられた場合、fix_hostname() はホスト名のポインターを -1 オフセット（盲目的にゼロレングスとして想定するため）でインデックス化し、
そのアドレスの読み込みおよび割り当ての両方を行います。

cURL 报告：

libcurl 保留最近几个使用过的连接池，以便促进应用程序轻松、便利和完全透明的连接重用。

进行经过认证的 HTTP 请求 NTLM 时，整个连接将得到认证，而不仅是特定 HTTP 请求，这本来是 HTTP 的工作方式。这使 NTLM 变得特殊并成为代码中特殊处理的主题。通过 NTLM，一旦该连接得到认证，连接关闭之前将不再需要任何其他认证。

进行经过认证的 HTTP 请求 Negotiate 时，整个连接可能得到认证，而不仅是特定 HTTP 请求，这本来是 HTTP 的工作方式，因为 Negotiate 基本上能够隐蔽地使用 NTLM。curl 不遵守这一事实，但会假设此类请求也将按照请求得到认证。

libcurl 支持 HTTP“cookie”，如 RFC 6265 中所述。结合每个 Cookie，将存在多个不同属性，但对于此漏洞，我们关注相关的“path”元素。
它提供关于 Cookie 在指定主机上的哪个路径中有效的信息。

内部 libcurl 函数调用的 sanitize_cookie_path() 清理来自远程站点或从文件中读取的 path 元素，该函数未正确验证输入。如果提供由单个双引号构成的路径，libcurl 会用索引 -1 为新分配的内存区域制作索引并向其分配 0，从而破坏其本不应破坏的堆内存。

libcurl 中有一个调用 fix_hostname() 的专有函数，如果主机名末尾有点，则删除该点。从通知 libcurl 操作的 URL 中提取主机名之后将调用该函数。

如果为 URL 提供了零长度主机名，例如“http://:80”或只有“:80”，fix_hostname() 将以 -1 偏移为主机名指针制作索引（因为它盲目地假设零长度）并同时读取和分配该地址。

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 位移索引主機名稱指標 (在其盲目地假設
非零長度時)，然後讀取及指派該位址。

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
83842	FreeBSD : cURL -- multiple vulnerabilities (6294f75f-03f2-11e5-aab1-d050996490d0)	Nessus	FreeBSD Local Security Checks	2015/5/27	2021/1/6	medium
83842	FreeBSD：cURL -- 複数の脆弱性（6294f75f-03f2-11e5-aab1-d050996490d0）	Nessus	FreeBSD Local Security Checks	2015/5/27	2021/1/6	medium
83842	FreeBSD：cURL -- 多种漏洞 (6294f75f-03f2-11e5-aab1-d050996490d0)	Nessus	FreeBSD Local Security Checks	2015/5/27	2021/1/6	medium
83842	FreeBSD：cURL -- 多個弱點 (6294f75f-03f2-11e5-aab1-d050996490d0)	Nessus	FreeBSD Local Security Checks	2015/5/27	2021/1/6	medium

检测

插件搜索

medium

medium

medium

medium