ディープダイブ重大性の高い libcurl/curl の脆弱性の発見と修正

ほんの少し前、セキュリティ・コミュニティと開発コミュニティは、curlプロジェクトのリード開発者であるダニエル・ステンバーグ（Daniel Stenberg）氏からの勧告で注意を喚起された。彼は、10月11日に配布されたcurlの新バージョンが、2つの重大なセキュリティ脆弱性に対処するためにリリースされたという不幸な知らせを伝えた。

Stenberg氏のブログの事後報告によると、影響を受けるバージョンのcurlライブラリには、ヒープベースのバッファオーバーフローの脆弱性があり、2002年以来使用されているSOCKS5プロキシ・プロトコルのレガシー問題に関連しているという。

コマンドラインツールとしての使用は1998年まで遡り、curlはインターネットの基礎となる柱として広く見なされている。このような歴史があり、広く使用されているcurlは、脆弱性が発見された場合、一般的なサイバーセーフティに継続的な影響を及ぼす可能性がある依存関係である。

この事件は、Log4jの壊滅的なLog4Shell攻撃と共通点がある。Log4jもまた脆弱な依存関係であり、2年近く経った今でも悪用されている。
‍
>>curl Missionで、今すぐあなたの知識をテストしよう！‍

脆弱性バッファオーバーフロー

この悪用はCVE-2023-38545で詳述されており、バージョン7.69.0から8.3.0までのcurlに影響を与える。主なバグはヒープベースのバッファ・オーバーフロー脆弱性で、悪用に成功すると、より壊滅的なリモート・コード実行（RCE）攻撃につながる可能性があるとの初期報告がある。これは脅威行為者にとって可能性のあるワークフローではあるが、想定されるケースというよりは稀なユースケースである。

おそらく、リスクを軽減する1つの救いは、悪意のある通信がSOCKS5プロキシを経由しなければならないことであり、これは比較的まれな展開である。

curlエクスプロイトと同様に、このバッファ・オーバーフローの説明を見てみよう：

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

クライアントとプロキシ間のハンドシェイクが遅い場合、(短い)解決された アドレスの代わりに長いホスト名がメモリバッファにコピーされる可能性がある。割り当てられたメモリ部分は255バイトの値しか許さないので、この制限を超える値を受け取ると、データはメモリバッファの境界をオーバーフローしてしまう。

>>> このミッションで試してみてください。 プレイアブル・ミッション!

バッファ・オーバーフローは強力な攻撃ベクトルであり、多くのレガシー・プログラミング言語で蔓延している可能性がある。この特殊なケースでは、悪用された結果、文脈によってはRCEという形で、より深刻で有害な攻撃への道が開かれた。

バッファオーバーフローのリスクを軽減するには？

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

一般的に、バッファオーバーフローの欠陥は、Rustのようなメモリセーフ言語を使用することで軽減することができるが、curlのような広大なプロジェクトのように、他の言語に移植したり、気まぐれに書き換えたりすることは現実的ではない。メモリー・セーフ言語で書かれた依存関係をより多く使用しサポートする可能性について、あるいはcurlの一部を少しずつ置き換えていくという選択肢について、Stenbergが述べているように、「......開発は......現在、氷河期に近いスピードで行われており、その課題が痛いほど明確に示されている。これは小さな仕事ではないし、セキュリティへの影響も計り知れない。

セキュリティ上のミスは起こりうるものであり、またこれからも起こりうるものである。したがって、これらのバグとの戦いにおける最大の武器は、継続的なセキュリティ意識とスキル向上に取り組むことである。
‍

安全なコードを書き、リスクを軽減する方法についてもっと知りたいですか？

私たちの ヒープオーバーフローに無料で挑戦.

無料のコーディング・ガイドラインにご興味のある方は、以下をご覧ください。 セキュアコードコーチをご覧ください。