CVEに関する異議申し立て

数年前、curlプロジェクトはCVE採番機関（CNA）に登録し、自らCVE識別子を割り当てることができるようになりました。自分たちの管轄内のセキュリティ問題については、その問題にCVEを付与するかどうかを自分たちで決定します。もう不正なCVEはありません。 57件のCVE この数年間で、私たちは57件の個別のセキュリティ脆弱性を、関連するCVE識別子とともに公開してきました。CNAであれば、問題に対するCVEの取得は簡単で、非常に迅速に行えます。手間も摩擦もなく、私たちは小規模で効率的なセキュリティチームなので、望みうる限りスムーズに機能します。APIコール一つで新しい番号が手に入ります。CNAであることはメンテナンスが少なく、実際に追加でやるべきことは何もありません。私たちは責任ある、適切に運営されているオープンソースプロジェクトであるため、脆弱性レポートの受信、管理、評価に関する確立された実績のあるプロセスをすでに持っていました。CNAになったことで、外部の人間を一切関与させる必要がなくなり、プロセスがさらに容易になりました。 評価 すべてのレポートに対して、私たちはまず、その問題が実際に脆弱性やセキュリティ問題であるかどうかを評価し、決定するために懸命に努力します。セキュリティ問題であると判断した場合、次にLOW、MEDIUM、HIGH、CRITICALのいずれかに等級分けします。ユーザーがcurlやlibcurlをどのように使用しているかは分からないため、それを考慮に入れることはできません。むしろ、純粋なcurlの観点から問題の深刻度を観察し、設定します。これは、私たちが問題をどのように見ているかのラフな指標ですが、もちろん、実際に問題の影響を受けているすべてのユーザーは、異なる評価をする可能性があります。 LOW未満 ごく一部の問題については、ごくわずかなリスクが存在する可能性があると想像できますが、それに到達するための極端な要件と複雑な手順のセットのため、リスクは非常に小さいと判断し、実際にはどのユーザーもそれに到達することはまずないでしょう。内部的には、これを「LOW未満」の深刻度レベルの問題と呼んでいます。CVEを発行しないことで、人類により良いサービスを提供できると信じている問題です。不必要と思われる場合に、セキュリティダンスを避けるためです。 CVEのコスト libcurlは世界中で約300億インスタンスにインストールされています。これらのインストールのかなりの部分が、安全なバージョンを使用したいと考えている人々によって管理されていると想像すると、私たちが公開するすべてのCVEが世界中の多くのセキュリティチームに活動を引き起こし、かなりの数のパッチとそれに続くソフトウェアアップデートにつながることを意味します。したがって、すべてのCVEにはこの巨大なコストが付随しています。そのコストは私たちにかかるものではなく、私たちは実際に見たり感じたりしませんが、エコシステムにかかるコストであり、無視すべきではないと私は信じています。私たちは責任を持って行動すべきです。もちろん、実際の問題を無視してはなりませんが、理論的な問題のために警報を鳴らさないようにすることも重要です。それは、いかなる脆弱性も引き起こさないでしょう。 論争 CNAになってから初めてのCVE論争は、2ヶ月前に私たちに提出されたレポートに対して、2026年2月10日に私たちに届きました。報告者は、彼らが報告した問題にCVEを割り当てるべきだと考えていますが、私たちはそうは思いません。今、彼らはMITREに状況をエスカレートさせることで、とにかくCVEにするように強制しようとしています。はい、なぜこれがCVEとしてそれほど重要なのか疑問に思いますが、今のところ憶測は避けます。MITREに返信し、問題を検討し、議論したこと、そして以前の決定に満足していることを説明しました。元のレポートと議論へのリンクを添付して、それらを示しました。 先頭にドットが付いたホスト名 問題は非常に技術的（もちろん）ですが、証明書で提供されたワイルドカードと使用されたホスト名が一致するかどうかをチェックするcurlの関数のバグに基づいています。まず、ユーザーはURLで先頭にドットが付いたホスト名を使用する必要があります。例: https://.example.com/ この名前はDNSでは使用できません（そこでは不正な名前です）。しかし、/etc/hostsファイルなどでIPアドレスを提供することはできます。それでも、この条件はすでにこの問題を非常にニッチなものにしています。ユーザーはなぜこのようなことをするのでしょうか？まあ、アプリケーションがリダイレクトを許可している場合、悪意のあるサーバーからそのようなホスト名へのリダイレクトがあるかもしれませんが、ホストのアドレスを取得することは依然として課題であり、ほとんどの場合、ローカル攻撃者の存在が必要です。次に、curlが不正なDNSホスト名のアドレスを見つけることができ、curlが接続するサイトも、URL内の名前と一致するワイルドカードが必要な*.example.comの名前のワイルドカード証明書を持っている必要があります。curlがTLSにOpenSSLフレーバーまたはSchannelを使用するようにビルドされている場合（curlは多くの異なるTLSバックエンドをサポートしていることを忘れないでください）、Curl_cert_hostcheck()関数を呼び出して、ワイルドカードが使用されたホスト名と一致するかどうかをチェックします。この関数にはバグがありました。上記の組み合わせは、実際には仕様に従って一致しないにもかかわらず、誤ってTRUE（一致）を返していました。私たちは2025年12月8日にこの問題を修正し、このシナリオに正確に対応する単体テストを追加して、問題が再発しないようにしました。HIGH未満のすべてのセキュリティ問題に対して、私たちはできるだけ早く修正するため、それは通常のプロセスでした。その後、これがCVEに値するかどうかを議論し続けました。 LOW未満 DNS以外のものを使用して解決している、内部的で管理された環境にいない限り、ドットで始まる名前を使用する人は非常にまれであるはずです。解決に失敗するため、アプリケーションをドットで始まる任意の名前の使用にだますことはできません。明示的に設定された、奇妙なドットで始まる名前は、その同じ名前に対してワイルドカードが設定されているホストに接続する必要があり、攻撃者はこの偽装ホストを実行でき、curlがワイルドカードの不一致のために接続を適切に拒否しなかったため、アプリケーションに悪意のあるデータを配信できるようになります。これが脆弱性になるためには、すべて満たされる必要がある、非常にありそうもない条件の連鎖です。LOW未満の状況です。あまりにもありそうもないため、CVEはありません。 再び5月に 5月28日、MITREから同じ件で再び連絡があり、この問題にCVEを与えなかった理由を再度尋ねられました。私たちは、以前とほぼ同じ言葉で応答し、同じ元のHackeroneの問題と議論スレッドに再度リンクしました。すべて公開情報です。 再び6月に 6月15日、MITREから再び連絡があり、この問題にCVEを与えなかった決定の理由を尋ねられました。私たちは、同様の言葉で再度返信しました。同じ問題に、再びリンクしました。これは素晴らしいシステムのように思えます。 評決 6月24日、ついに評決が得られました。セキュリティ脆弱性とは見なされません。 こんにちはYuhaoさん、 curl 8.17.0に影響する報告された問題に関するCVE論争プロセスへのご参加ありがとうございます。 MITRE TL-Rootは、あなたから提出された資料と責任あるCNAからの応答を含む、関係者全員から提供された情報のレビューを完了しました。このレビューに基づき、MITRE TL-Rootは、報告された問題に対してCVE IDは割り当てられないと判断しました。 CNAの決定（概要）： 「これはバグであり、現在マスターブランチで修正されています。ローカル攻撃者が特権を持って存在する必要があるため、セキュリティ脆弱性とは見なされません。」 利用可能な証拠とCNAの評価を評価した後、MITRE TL-Rootはこの決定に同意し、問題を解決済みと見なします。この論争プロセスにおける裁定機関として、MITRE TL-Rootの決定はこのケースの最終的な決定となります。 CVEプログラムへのご参加と、セキュリティ問題の責任ある報告と調整へのご尽力に感謝いたします。 敬具、 MITRE TL-Root Yuhaoは当時、Grokにも不平を言ったようです。https://x.com/grok/status/1998584974342238397 Daniel、これをやってくれて本当に本当にありがとう。私のCVE論争プロセスの経験には、ユーザーがサーバーに物理的にアクセスし、ソフトウェアをロードし、rootとしてログインし、メモリをスクレイピングしたときに機密データを見ることができたため、CVEを開いたという提出が含まれます。はい、正しく読みました。そしてMITREは承認しました。私たちは