Curlでヒープオーバーフローを作る方法

• curl 8.4.0で発見された重要なセキュリティ問題 CVE-2023-38545 に関する記事で、長年にわたり curl で最も深刻なセキュリティ問題と見なされている
• 問題はヒープオーバーフローで、SOCKS5 プロキシに接続する関数の欠陥によって発生する
• この問題は、2020年初頭にその関数がブロッキング呼び出しからノンブロッキングのステートマシンに変換された際に導入されたもので、SOCKS5 経由の大量並列転送の性能向上のために行われた
• 欠陥はステートマシンの INIT 状態にあり、そこでローカル変数が設定され、curl がホストを解決するか、名前をプロキシに渡すかを決定する。ホスト名が長すぎる場合、コードはローカル解決モードに切り替わり、ホスト名が対象バッファより長いとメモリオーバーフローを引き起こす可能性がある
• バッファサイズが 65541 バイト未満に設定され、ホスト名がバッファサイズより長い場合、オーバーフローが発生する可能性がある。これは、悪意ある行為者が式に超巨大なホスト名を入力して欠陥を誘発することを必要とする
• libcurl を使用するクライアントが SOCKS5 プロキシ経由でアクセスする HTTPS サーバーを攻撃者が制御している場合、HTTP 30x 応答を通じてアプリケーションに細工されたリダイレクトを返し、ヒープバッファオーバーフローを引き起こす可能性がある
• この問題は curl 8.4.0 で修正され、ホスト名が長すぎる場合にはリモート解決からローカル解決に切り替える代わりに curl がエラーを返すようになった。このシナリオ専用のテストケースも追加された
• 著者は、この欠陥は curl が C ではなくメモリ安全な言語で書かれていれば発生しなかっただろうと認める一方、curl を他の言語へ移植する計画は現時点ではないと述べている
• 著者は、メモリ安全な言語で書かれた依存関係をより多く受け入れ、利用し、支援することが現実的なアプローチであり、将来的には curl の一部を段階的に置き換えることもあり得ると提案している
• 著者はミスを認めて謝罪し、この欠陥はより良いテストセットがあれば検出できたはずだと述べている。また、この関数の問題を発見できなかった静的コード解析器にも言及している
• 著者は、200億以上のインスタンスにインストールされたコードでヒープオーバーフローを送り出すことは勧められるような経験ではない、という結論で締めくくっている

[GN⁺]

Hacker Newsの意見

• 多くの機器で使われている Curl ライブラリのヒープオーバーフロー問題に関する記事で、このライブラリは主に一人の人物によって書かれている。
• Curl の作者である Daniel は、1315日間コード内で発見されなかった欠陥によるミスについて謝罪した。
• 記事は、Curl が C ではなくメモリ安全な言語で書かれていれば、メモリ安全性の問題は避けられた可能性があると示唆している。
• 著者は、Curl の一部をよりメモリ安全な言語に段階的に置き換える可能性を検討しているが、そのような開発の進みが遅いことも認めている。
• 著者は、Curl のセキュリティ脆弱性のうち 41% はメモリ安全な言語であれば回避できたはずだと主張している。
• この記事は、問題の背後にある論理と視点を説明する、明快で率直な文章として評価されている。
• 一部のコメントは、攻撃ベクトルが非常に小さく、悪用にはきわめて限定的な条件が必要だとして、この問題の深刻さに疑問を呈している。
• あるコメントは、検閲回避ツールを使う人々に対し、DNS を通じてユーザーの身元を漏えいさせうるコード部分を批判している。
• 別のコメントは、著者が RFC1123 で明示された DNS ホスト名の制限を無視しており、これが問題に寄与した可能性があると指摘している。
• 最新の Windows 10 セキュリティ更新プログラムに、新しいバージョンの Curl が含まれていなかったことにも言及されている。