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 オフセット（盲目的にゼロレングスとして想定するため）でインデックス化し、
そのアドレスの読み込みおよび割り当ての両方を行います。

検出

FreeBSD：cURL -- 複数の脆弱性（6294f75f-03f2-11e5-aab1-d050996490d0）

medium Nessus プラグイン ID 83842

変更ログが見つかりません