徹底解説：libcurl/curlにおける深刻な脆弱性の発見と修正

少し前、セキュリティおよび開発コミュニティに、curlプロジェクトのリード開発者であるダニエル・ステンバーグ氏から警告が発せられました。同氏は、残念な知らせとして、10月11日にリリースされたcurlの新バージョンで、2つの重大なセキュリティ脆弱性が修正されたことを報告しました。そのうちの1つについて、彼は「ここ最近で最悪のcurlのセキュリティ欠陥」と評しています。

ステンバーグ氏のブログでの事後検証によると、curlライブラリの対象バージョンには、2002年から使用されているSOCKS5プロキシプロトコルのレガシーな問題に起因する、ヒープベースのバッファオーバーフロー脆弱性が存在します。

1998年からコマンドラインツールとして利用されているcurlは、インターネットの基盤を支える重要な柱として広く認識されています。これほど長い歴史を持ち、広く普及している依存関係であるからこそ、脆弱性が発見された場合、サイバーセキュリティ全体に継続的な影響を及ぼす可能性があります。

今回のインシデントは、Log4jで発生した壊滅的なLog4Shell攻撃と類似しています。Log4jもまた、脆弱な依存関係として、発生から2年近く経った今でも悪用され続けています。
‍
>>> curlミッションで、今すぐあなたの知識を試してみましょう！‍

脆弱性の詳細：バッファオーバーフロー

この脆弱性はCVE-2023-38545として報告されており、curlバージョン7.69.0から8.3.0までが影響を受けます。主なバグはヒープベースのバッファオーバーフローであり、初期の報告では、悪用が成功すればより深刻なリモートコード実行（RCE）攻撃につながる可能性があると指摘されています。攻撃者にとって可能な攻撃経路ではありますが、これは一般的なケースではなく、稀な事例です。

リスクを軽減する唯一の救いは、悪意のある通信がSOCKS5プロキシを経由する必要があるという点であり、これは比較的珍しい構成です。

curlの脆弱性と比較して、こちらのバッファオーバーフローの解説をご覧ください：

curlがSOCKS5プロキシを使用するように設定されている場合、ホスト名をプロキシに渡し、プロキシ側で解決させます。しかし、ホスト名が255バイトの制限を超えると、curlはホスト名をローカルで解決してしまいます（以下のコードスニペットを参照：ソース）。

クライアントとプロキシ間のハンドシェイクが遅延した場合、長いホスト名が（短い）解決済みアドレスの代わりにメモリバッファにコピーされる可能性があります。割り当てられたメモリ領域は255バイトの値しか許容しないため、この制限を超える値を受け取ると、データがメモリバッファの境界を越えて溢れ出してしまいます。

>>> ぜひ体験型ミッションで実際に試してみてください！

バッファオーバーフローは強力な攻撃ベクトルであり、多くのレガシーなプログラミング言語で一般的になり得るものです。今回のケースでは、特定の状況下でRCEというより深刻で有害な攻撃につながる可能性がありましたが、そのような攻撃経路は依然として一般的ではなく、可能性も低いものです。

バッファオーバーフローのリスクをどのように軽減できますか？

現段階で最も優先すべき対策は、脆弱性のあるすべてのインスタンスにパッチを適用することです。curlは非常に広く利用されているため、システムのコンポーネントにこの依存関係が含まれていることが必ずしも明確ではない、あるいは公表されていない可能性があることに注意してください。その場合は、監査とそれに続くパッチ適用が必要です。

一般的に、バッファオーバーフローの欠陥はRustのようなメモリセーフな言語を使用することで軽減できます。しかし、curlのように巨大なプロジェクトの場合、別の言語に移植したり、一から書き直したりすることは現実的ではありません。ステンバーグ氏が指摘しているように、メモリセーフな言語で書かれた依存関係の利用や、curlの一部を段階的に置き換えるといった議論はありますが、「……開発は……現在、氷河のような遅さで進んでおり、その困難さが痛いほど明確に示されています。curlは当面の間、C言語で書かれ続けるでしょう」。これは決して小さな取り組みではなく、セキュリティへの影響は甚大です。

セキュリティ上のミスは起こり得るものであり、スキャナーやテストですべての攻撃ベクトルを検知できるとは限りません。したがって、こうしたバグとの戦いにおいて最大の武器となるのは、継続的なセキュリティ意識の向上とスキルアップへの取り組みです。
‍

セキュアなコードの書き方やリスク軽減について、さらに詳しく学びたいですか？

当社の ヒープオーバーフロー・チャレンジを無料でお試しください。

コーディングに関する無料ガイドラインをご希望の方は、Secure Code Coachをぜひチェックしてください。セキュアコーディングのベストプラクティスを常に把握するのに役立ちます。