Skip to main content

libcurlとcurlで重大度の高い脆弱性を発見(CVE-2023-38545)

著者
Headshot of Hadas Bloom

Hadas Bloom

feature curl vuln

2023年10月4日

0 分で読めます

更新:2023年10月11日

本日06:00 UTC、cURLのメンテナーは、特定の構成と前提条件下のシステムに影響する可能性のある、重大度の高いヒープベースのバッファオーバーフロー(概念実証および初回通知)を緩和するため、curlとlibcurlのバージョン8.4.0をリリースしました。

このゼロデイ脆弱性は、C/C++、cargo、cocoapods、npm、NuGet、pip、pubなど、複数の管理対象・非管理対象のオープンソースエコシステムのパッケージに存在します。また、Alpine、Debian、RHELなど、さまざまなLinuxディストリビューションにも影響します。

これはcurlで数年ぶりに発見された重大度の高い脆弱性です(前回は2021年初頭でした)。

cURLとlibcurlの脆弱性一覧のスクリーンショット。最近のバージョンごとの色分けされた深刻度バーと合計件数が表示されています。
cURLの脆弱性一覧のスクリーンショット

影響を受けるcurl/libcurlのバージョン(2020年3月以降)は次のとおりです。

  • 影響を受けるバージョン:libcurl 7.69.0から8.3.0まで(両バージョンを含む)

  • 影響を受けないバージョン:libcurl 7.69.0未満、および8.4.0以上

この脆弱性の悪用難易度はhighと考えられており、特定の状況でのみトリガーされます。メンテナーによる投稿「How I made a heap overflow in curl」で説明されているように、脆弱なライブラリが、HTTPリダイレクトを介して悪用される制御されていないサーバーまたは侵害されたサーバーに接続しているか、ホスト名解決を有効にしたSOCKS5プロキシ経由で攻撃者が制御するURLを使用している必要があります。しかも、その場合でもヒープオーバーフローを引き起こせる文字セットは限定されています。最新のシステムでヒープオーバーフローを任意コード実行(ACE)につなげるのは非常に困難であり、これが悪用難易度が高い理由です。

脆弱性が公開され、追跡できるようになったため、Snykのレポート機能を使って影響を受けるプロジェクトを確認できます。組織を選択し、サイドバーのレポートを選択してください。「問題の詳細」の下にある+フィルターを追加を選択し、CVEを選択して、CVE番号CVE-2023-38545を入力します。

CVEフィルターを開き、ドロップダウンでCVE-2023-38545を選択したSnyk Issues Detailレポート
CVE-2023-38545に絞り込んで表示

新しい情報が入り次第、このブログを更新します。

更新:2023年10月4日

2023年10月3日、長年curlのメンテナーを務める原作者のDaniel Stenberg氏が、LinkedInとX(旧Twitter)で、バージョン8.4.0のcurlの提供について投稿しました。このバージョンには、「curlで長い間に見つかった中で、おそらく最悪のセキュリティ問題」に対する修正が含まれます。この問題は深刻に受け止める必要があります。これまでcurlのメンテナーは、curlに報告される多くの脆弱性のリスクを軽視してきたと率直に述べてきました(最近の例は「CVE-2020-19909 is everything that is wrong with CVEs」です)。しかし今回の特別なケースでは、リスクについてあえて明確に警告し、「覚悟しておいてください」と呼びかけています。

メンテナーによると、修正版の8.4.0は2023年10月11日06:00 UTCごろにリリースされる予定です。

本日(2023年10月4日)、脆弱性情報の掲載に使用されるCVEが、GitHubのディスカッションで発表されました。

CVE-2023-38545は、libcurlとcurlの両方に影響する重大度の高い問題に割り当てられます。また、libcurlのみに影響する重大度の低い問題には、CVE-2023-38546が割り当てられ、こちらも修正されます。

現時点で分かっていること

cURLは、URL転送に使用されるlibcurlライブラリと、URLを使ったデータの取得・送信に使用されるコマンドラインツールcurlを提供する人気のプロジェクトです。cURLは27年前に初めてリリースされ、1996年以来、広く利用されています。

SnykがサポートするLinuxディストリビューションの多く、あるいはすべてでlibcurlが使用されているため、影響が及ぶ範囲は広い可能性があります。

修正に備える方法

  • コンテナとパッケージの使用状況を事前に確認し、影響を把握する

  • curlがインストールされているホストを特定し、インストール方法を確認する

  • curl --versionを実行して、使用中のcurlのバージョンを確認する

影響範囲を把握する

libcurlの修正版がリリースされる前に、Snykを使って、影響を受ける可能性のあるオープンソースプロジェクトやコンテナイメージをすばやく見つけられます。

SnykアプリのUIサイドバーで依存関係に移動します。依存関係ビューを開いたら、「依存関係」フィルターを展開し、「curl」と入力します。個別のバージョンを選択するか、すべて選択のショートカットをクリックし、フィルターの外側をクリックすると結果が表示されます。選択したバージョンのlibcurlを含むプロジェクトがすべて表示されます。プロジェクトと依存関係をさらに確認し、影響範囲を把握して、優先して修正すべきものを判断できます。

curlがインストールされているホストを特定する

多くのオペレーティングシステムにはcurlが標準でインストールされていますが、インストール場所はOSやインストール方法によって異なります。次のコマンドを実行すると、curlがインストールされていて、パスが通っているかをすばやく確認できます。curl --version

エラーが表示されずにコマンドが終了した場合、パス内で最初に見つかったcurlのバージョンが表示されます。複数の場所にインストールされている場合もあります。たとえば、最近のApple製コンピューターには/usr/bin/curlが標準で付属していますが、Homebrew経由でもインストールされている可能性があります。パス内のバージョンの場所は、which curlを実行して確認できます。macOSやLinuxベースのOSでは、ほかに次の場所も確認してください。

  • /bin/curl

  • /usr/bin/curl

  • /usr/local/bin/curl

  • /opt/homebrew/opt/curl

新しいバージョンに備え、更新が必要な箇所をすべて見つけてください。

アップデートのリリース後に行うこと

リリース予定日の2023年10月11日06:00 UTCごろには、バージョン8.4.0にアップデートできるよう準備してください。新バージョンが公開され次第、Snykは脆弱性に関する追加情報を公開し、このブログを更新します(今後公開する関連記事もこちらにリンクします)。

脆弱なパッケージとコンテナを更新する

準備段階で収集した情報を活用し、プロジェクトとコンテナイメージを更新して、修正版のlibcurlを取り込みます。エコシステムやLinuxディストリビューションによっては、この時点以降に影響を受けるパッケージのアップグレードを待つ場合があり、修正の提供時期は段階的になる可能性があります。たとえば、上流の修正を待ってからコンテナイメージやパッケージの更新をリリースするメンテナーもいれば、既存のものに直接パッチを適用するメンテナーもいます。いずれの場合も、Snykを使って問題を見つけ、修正できます。

デバイス上のcurlを更新する

修正版のcurlバイナリが提供されたら、インストール済みのバージョンを更新してください。別の記事で更新に役立つヒントをご紹介します。curlのインストール方法は複数あり、更新方法はOSによって異なります。

Snykの対応

Snykは、上流で発見された重大度の高い問題に関するプレースホルダーアドバイザリを公開しました。プレースホルダーの内容は、新たに判明した情報に応じて更新されます。

Snykのセキュリティ専門家は、リリースの更新、脆弱性情報、ソーシャルメディア上の動向などを継続的に追跡し、新たな情報をお客様に提供しています。また、影響を受ける可能性のある下流パッケージがほかにないか調査しています。必要に応じてこのブログを更新します。

カテゴリー:

続きを読む

Blog

フロンティアモデルは脆弱性を発見した。攻撃者だけがエクスプロイトチェーンを見つけた。

静的解析で欠陥は見つかりましたが、ライブ攻撃テストで侵害につながる連鎖を実証できたのは唯一でした。Evo COS、Claude Security、Claude Code Securityを比較します。

feature insights context
Blog

自律型攻撃はすでに始まっている。防御もそのスピードに追いつかなければならない。

自律型攻撃者によって、防御に使える時間は短くなっています。継続的な検出、修復、検証、予防で、セキュリティチームが攻撃に歩調を合わせる方法をご紹介します。

Blog

脆弱性のバックログはもはや技術的負債ではなく、攻撃対象領域です

増え続ける脆弱性のバックログは、単なる技術的負債ではありません。攻撃対象領域そのものです。古いリスクの前提、攻撃の自動化、そして連鎖する検出結果によって、なぜ新たなアプローチが求められているのかを解説します。