cURL は、ファイル転送を目的としたライブラリとコマンド インタプリタで構成されるソフトウェア プロジェクトです。
Daniel Stenberg (cURL プロジェクトの作者) 最近発表された ブログ投稿を通じて、に関する情報 で検出された脆弱性 ネットワーク経由でデータを送受信するユーティリティ curl と libcurl ライブラリ。
この脆弱性 (すでに CVE-2023-38545 としてカタログ化されている) について言及されています。 ホスト名解決コードのバグが原因です SOCKS5 プロキシにアクセスする前に。
SOCKS5 はプロキシ プロトコルです。 これは、専用の「ブローカー」を介してネットワーク通信を設定するための非常に単純なプロトコルです。 たとえば、このプロトコルは通常、Tor を介した通信を設定するときに使用されますが、組織や企業からインターネットにアクセスする場合にも使用されます。
SOCKS5 には XNUMX つの異なるホスト名解決モードがあります。 クライアントがローカルでホスト名を解決して宛先を解決されたアドレスとして渡すか、クライアントが完全修飾ホスト名をプロキシに渡してプロキシがリモートでホストを解決できるようにします。
ということで失敗 バッファオーバーフローを引き起こす可能性があります また、curl ユーティリティまたは libcurl を使用するアプリケーションを通じて攻撃者が制御する HTTPS サーバーにアクセスすると、攻撃者のクライアント側コードが実行される可能性があります。 しかし問題は SOCKS5 プロキシ経由でアクセスする場合にのみ存在します カールで有効になります。 プロキシを介さずに直接アクセスする場合、脆弱性は発生しません。
SOCKS5 プロキシを介してcurlによってアクセスされるサイトの所有者は、次のことができると説明されています。
リクエスト リダイレクト コード (HTTP 30x) を返し、サイズが 16 ～ 64 KB (最大サイズは 16 KB) のホスト名を持つ URL に「Location:」ヘッダーを設定することで、クライアント側のバッファ オーバーフローをトリガーします。割り当てられたバッファがオーバーフローする可能性があり、URL で許可されるホスト名の最大長は 65 KB です)。
libcurl 設定でリクエストのリダイレクトが有効になっており、使用される SOCKS5 プロキシが十分に遅い場合、長いホスト名は明らかにサイズが小さい小さなバッファに書き込まれます。
彼のブログ投稿では、 Daniel Stenberg 氏は、この脆弱性は 1315 日間検出されなかったと述べました。 また、これまでに特定されたcurlの脆弱性の41%は、curlがメモリセーフな言語で書かれていればおそらく回避できたであろうが、予見可能な将来にcurlを別の言語で書き直す計画はないとも述べている。
この脆弱性は主に libcurl ベースのアプリケーションに影響します。 また、libcurl はデフォルトで 65541 KB のバッファを割り当て、curl では 16 KB を割り当てますが、このサイズは「 –limit-rate」パラメータ。
ホスト名が 256 文字までの場合、curl は解決のためにすぐにその名前を SOCKS5 プロキシに渡し、名前が 255 文字を超える場合は、ローカル リゾルバーに切り替えて、すでに定義されているアドレスを SOCKS5 に渡すことが記載されています。 。 コードのバグにより、SOCKS5 経由の接続の低速ネゴシエーション中に、ローカル解決の必要性を示すフラグが誤った値に設定される可能性があり、IP を保存することを期待して割り当てられたバッファに長いホスト名が書き込まれる可能性がありました。住所または名前は 255 文字を超えてはいけません。
最後に、 この脆弱性はcurlバージョン8.4.0で修正されました。 コードベースのセキュリティを向上させるための対策として、コードをテストするためのツールを拡張し、メモリでの安全な動作を保証するプログラミング言語で記述された依存関係をより積極的に使用することが提案されています。 また、curl の一部を、Rust に実装された実験的な Hyper HTTP バックエンドなど、安全な言語で書かれたオプションに徐々に置き換えることも検討しています。
もしあなたが それについてもっと知りたい、詳細を確認できます 次のリンクで。