Dev rejects CVE severity, makes his GitHub repo read-only
2024/06/30 BleepingComputer — 人気のオープンソース・プロジェクト node-ip の GitHub リポジトリが、その開発者の手により、先日にアーカイブ (読み取り専用) 状態になってしまった。その背景にあるのは、今年の始めに node-ip に対する CVE が提出されたことで、開発者である Fedor Indutny に対して、インターネット上のユーザーからの脆弱性の指摘が集中したことである。残念なことに、今回のケースは、彼に限った出来事ではない。このところ、オープンソースの開発者たちの間で急増しているには、自分のプロジェクトに対して提出された、議論の余地のある CVE レポートや、十分な確認もなしに提出された全くのインチキ CVE レポートを受け取るケースである。
こういった脆弱性の報告は、プロジェクトのユーザー間に不必要なパニックを引き起こし、また、セキュリティ・スキャナーによるアラート生成の可能性を生じるため、開発者たちの悩みの種になっている。
アーカイブされた “node-ip“ GitHub リポジトリ
2024年6月の初めに、node-ip の GitHub リポジトリは、開発者の Fedor Indutny によりアーカイブ (読み取り専用) 化されてしまった。それに伴い、同プロジェクトの新規課題 (ディスカッション) のオープン／プルリクエスト／コメント投稿などが制限された。
node-ip プロジェクトは、npmjs.com のレジストリに ‘ip’ パッケージとして登録されており、毎週 1,700万ダウンロードを誇る、JavaScript 開発者にとって最も人気の IP アドレス解析ユーティリティの一つである。
6月25日に Indutny は、node-ip をアーカイブ化する理由についてソーシャルメディアに投稿している。Indutny の投稿には、「ここ数ヶ月、ずっと頭を悩ませていたことがあった。そして、結果的に、GitHub の node-ip リポジトリをアーカイブ化することを決めた」と記されている。
彼の悩みの種となっていたのは、2024年の2月に公開された NPM IP package の脆弱性 CVE-2023-42282 である。彼は、「私の npm パッケージについて、不確かな CVE を申請した人がいる。そして私の元には、npm audit から警告を受けた全てのユーザーから、メッセージが届くようになった」と述べている。
npm audit とは、プロジェクトをスキャンして潜在的なセキュリティの脆弱性を特定し、見つかった問題に関するレポートを生成するコマンドだ。npm パッケージなどに代表される、依存関係のあるオープン・プロジェクトを使用している Node.js の開発者たちは、このコマンドを実行することで、自身のアプリケーションで使用しているプロジェクトに関して、脆弱性の報告の有無を確認できる。
この CVE が割り当てられた問題は、16進数などの非標準フォーマットで提供されたプライベートな IP アドレスを、ユーティリティが正しく識別できないことにある。それにより、node-ip ユーティリティは、プライベート IP アドレス (16進数で 0x7F.1… ) を、パブリック (127.1…) として扱うことになる。
したがって、提供された IP アドレスが公開されているかどうかをチェックするために、アプリケーションが node-ip だけに依存している場合において、さらに非標準の入力値が用いられる場合においては、このユーティリティの特定のバージョンでは、一貫性のない結果を返す原因が生じる。
セキュリティへの影響は “疑わしい”
脆弱性 CVE-2023-42282 が報告された当初は、CVSS スコアは 9.8 (脅威度：Critical) と評価されていた。この報告を受けた Indutny は、後にリリースした node-ip で、この脆弱性を修正した。しかし彼は、このバグが実質的な、それも深刻度が高い脆弱性であることに異議を唱えている。
以前に Indutny は GitHub に対して、この CVE を取り消すよう要請した。彼は、「この脆弱性のセキュリティへの影響について、かなり疑わしいと考えている。私は、このモジュールを、セキュリティ関連のチェックに使うつもりはなかった。しかし、ネットワーク接続がどこから来たのかを確認するために、信頼できない入力が ip.isPrivate や ip.isPublic 関数に渡されるという、非常に不可解なかたちで使われている」と述べている。
GitHub のセキュリティ・チームのメンバーが説明しているように、発行されてしまった CVE に対して異議を唱えるのは、容易なことではない。なぜなら、CVE を最初に発行した CNA (CVE Numbering Authorities ) を追いかける必要性が、プロジェクトのメンテナに生じるからである。
従来の CNA は、NIST の NVD と MITRE で構成されていた。しかし、ここ数年の間に、テクノロジー企業やセキュリティ・ベンダーも構成に加わり、彼らも自由に CVE を発行できるようになった。
これらの CVE は、脆弱性の説明や報告された深刻度の評価と一緒に、GitHub アドバイザリなどのセキュリティ・データベースによりシンジケートされ、再公開される。
ソーシャル・メディアに対する Indutny の投稿を受け、GitHub は、データベース内の CVE の深刻度を引き下げた。そして、入ってくる報告を制限してノイズを減らすために、開発者に対してプライベート脆弱性の報告をオンにするよう提案した。
なお、現時点において、 NVD による CVE-2023-42282 の深刻度は “Critical “のままとなっている。
増幅する厄介事
本来の CVE システムは、セキュリティ研究者たちが、プロジェクトの脆弱性を倫理的に報告し、責任を持って開示した後に、それらのカタログ化を支援するために設計されたものだ。しかし最近になって、検証されていない報告を提出するコミュニティ・メンバーが現れ始めた。
CVE の多くは、責任ある研究者により誠実に報告されたものであり、信頼できるセキュリティ脆弱性を示すものだ。しかし最近は、セキュリティの初心者やバグ賞金稼ぎが、悪用により現実に悪影響を与えるようなセキュリティ・バグを報告するのではなく、自分の履歴書を充実させるために “CVE を収集” するというケースが増えている。
そういった動向に、開発者やプロジェクトのメンテナたちは抵抗している。
2023年8月には、有名なソフトウェア・プロジェクト “curl” の開発者である Daniel Stenberg が、curl の脆弱性 CVE-2020-19909 は誤りであると非難する投稿をした。
NVD の履歴によると、この脆弱性の情報が公開された当時の CVSS スコアは 9.8 (深刻度 Critical) だった。しかし、この脆弱性がセキュリティに与える具体的な影響を疑問視する議論が続いたことで、現在も論争の的になっている、この CVE の評価は CVSS スコアは 3.3 (深刻度 Low) に引き下げられた。
Stenberg は CVE エントリーを批判し、「これは特別なケースではなく、また、初めて起こったことでもない。これは何年も続いてきたことだ。脆弱性をめぐる哲学的な思考訓練は好きではない。それらは現実の問題から目をそらすものであり、むしろ無意味だと思う。この欠陥が、どのように作用するのかは、多くのコンパイラを使って多くのプラットフォームで簡単にテストできる。どのプラットフォームでも、セキュリティ上の問題はない」と述べている。
彼によると、“愚かなバグ“ の技術的な詳細は、予期せぬ動作をもたらす可能性があることを意味しており、悪用される可能性のあるセキュリティ上の欠陥ではないという。
さらに、別の npm プロジェクトであり、毎週 6,400万件のダウンロードを誇る micromatch に対しては、深刻度 High の ReDoS 脆弱性が報告されており、この問題について問い合わせるコミュニティ・メンバーから、クリエイターが追われ続けている。
micromatch の 開発者である Jon Schlinkert は、脆弱性 CVE-2024-4067 の報告に対して、「”micromatch” や “braces” を実装しているライブラリで、この脆弱性の影響を受けやすいものを１つでも挙げてほしい。そうすれば、この脆弱性が机上の空論ではないことも分かるはずだし、実際に存在する脆弱性であることも分かるはずだ」と切り替えしている。
脆弱性レポーターから、彼は満足のいく PoC エクスプロイトを受け取れなかったようであり、その後に、同じスレッドに、「私の元には、このような、自分自身でやらない限り、脆弱性にすらなり得ないような報告がしょっちゅう届いている。低レベルのライブラリに含まれる正規表現のように、ブラウザからアクセスされることはないだろう。私は、実世界のライブラリで、どのように、これらの “脆弱性” が生じるのかを示す例を求めたが、あなたは例を挙げて答えなかった」というコメントを投稿している。
先日に筆者も、プロジェクトがもたらす潜在的な “リスク” について、第三者から報告を受けた後に、micromatch の開発者にメッセージを送った。残念なことに、それは悪用可能な脆弱性ではなく、CVE-2024-4067 のような、迷惑な報告という結果で終わってしまった。
検証されていない脆弱性報告に対して CVE を発行させるという行為は、プロジェクトのメンテナにとって迷惑なだけではない。プロジェクトや開発者に対して、そして、より広範なユーザーに対して、サービス拒否 (DoS) を引き起こすものにもなり得る。
開発者向けのセキュリティ・ソリューションである npm audit などは、脆弱性のあるコンポーネントがアプリケーションに到達するのを防ぐように設計されている。しかし、既知の脆弱性が検出されるとアラートが発せられ、設定によってはビルドが壊れる可能性がある。
2023 年には、curl の “偽の” CVE に対して、「Jackson では、数カ月前に、誰かがプロジェクトに対してクリティカルな CVE を報告したのが原因で、世界中のビルドが破壊された」というコメントが寄せられた。この問題は、他の開発者たちが述べているように、プロジェクトのセキュリティ上の問題というよりも、再帰的な Java データ構造の本質を表していた。
どのようにバランスを取ればよいのか？
このようなインシデントが繰り返されると、どのようにバランスを取るべきか、という疑問が生じる。
理論的な脆弱性を執拗に報告し続けることは、ボランティアである多くのオープンソースの開発者たちを、不必要なノイズで疲弊させることになりかねない。
しかし、その一方で、初心者を含むセキュリティ専門家たちが、プロジェクトのメンテナに迷惑をかけないようにと、セキュリティ上の欠陥と思われるものを看過することは、はたして倫理的に正しいことなのだろうか？
そして、第三の問題は、積極的なメンテナがいないプロジェクトの存在である。何年にもわたりメンテナンスされていない、放置されたソフトウェア・プロジェクトでは、たとえ脆弱性が発見／公開されても、修正されることがなく、メンテナに連絡する手立てもない。
このようなケースにおいて、CNA やバグバウンティ・プラットフォームなどの仲介者は、お手上げ状態になってしまう。
研究者からの脆弱性報告を受けた際に、これらの組織が、すべての報告に対して、十分に吟味できるとは限らない。今は不在の、プロジェクト管理者からの連絡がなければ、”責任ある情報公開” の期限が過ぎた後に CVE を割り当て、公表せざるを得ないのかもしれない。
これらの問題に対する明確な解決策は、まだ見つかっていない。
セキュリティ研究者／開発者／ベンダーの各コミュニティが、一体となって効果的な解決策を見出すまでは、開発者たちはインチキ報告に苛立ち続けるだろう。そして、CVE システムには、書類上は信頼できそうでも、事実上は無意味でありる誇張された ”脆弱性” が氾濫する状況が続いていくだろう。
とても興味深い指摘がなされている記事です。翻訳に３時間、校正に２時間を要するという、このブログ・チームにとっての大作になりました。それでも、訳すべきだったし、訳してよかったと思っています。話は飛びますが、最近、池田晶子という哲学者 (故人) の本を読んだりしています。氏によると、人の行動 (善行) には倫理的なものと道徳的なものがあるそうです。 平たく言うと、個に属するものと、公に属するものになります。この２つがバランスよく共存することで、人間の社会は成り立っているのだろうと思いますが、しばしば衝突も起こします。この記事を訳していて、倫理と道徳が、何度か頭をよぎりました。
IoT OT Security News 
You must be logged in to post a comment.