この脆弱性の開示は、セキュリティ研究者がベンダーに何を期待すべきか、また公開前にどのくらいの期間を置いてバグを通知すべきかという問題を提起しています。
GitHubのブラウザ版VSCodeエディタに脆弱性が存在し、特定の条件下では開発者のトークンが窃取される可能性があると、セキュリティ研究者が指摘しています。
この問題は、Ammar Askarが今週公開したブログで明らかになりましたが、GitHubの親会社であるMicrosoftによってすでに対処されたようです。しかし、DevOpsセキュリティ全般にわたる問題提起にとどまらず、「Microsoftがバグ発見を真剣に扱わないため、見つけた脆弱性を公開する際に短い告知期間しか与えないことは正当化できる」という研究者の主張についても、疑問を投げかけるものとなっています。
まず脆弱性の内容についてですが、github.comのユーザーの多くは気づいていないかもしれません。しかし実は、任意のリポジトリを閲覧中にURLを変更するだけで、github.devのブラウザ版VSCodeに切り替えることができます。
なぜこれを使うのでしょうか。Askarはブログの中で、ブラウザ版VSCodeは非常に強力だと述べています。「リポジトリ内のすべてのファイルを閲覧でき（プライベートリポジトリであっても）、プルリクエストの送信やコミットまで行えます。」
Rob Enderle氏は、Enderle GroupのITコンサルタントとして、この方法でVSCodeに切り替えることは「素早いタスクのための非常に便利な戦術的ツールだ」と同意しています。「GitHubの任意のリポジトリで『.』キーを押すだけで、ギガバイト単位のデータをローカルにクローンすることなく、ブラウザ版VS Codeのインターフェイスをすぐに利用できます。ワークフローを中断させることなく、PRの素早いレビュー、ドキュメントの簡単な編集、コードの閲覧などに最適です。ただし、ブラウザのサンドボックス内で完全に動作しており、コンピュートバックエンドもターミナルもコード実行機能もない点は念頭に置いておく必要があります。」
負荷の高い処理や実際のコンパイルには、依然としてローカルワークステーションの処理能力、またはCodespacesのようなフルクラウド環境が必要になると同氏は付け加えています。
問題は、この機能がgithub.comからgithub.devへOAuthトークンをPOSTすることで実現されている点にあるとAskarは指摘しています。このトークンにより、github.devはユーザーに代わってGitHubを操作できるようになります。「このトークンは、操作した特定のリポジトリにスコープが限定されていません。つまり、あなたがアクセス権を持つすべてのリポジトリに対してフルアクセスが可能な状態です」と同氏はブログに記しています。
「このトークンの存在に加え、このWebアプリがVSCodeの100万行規模のTypeScriptコードベースのほぼ全体を実行していることから、VSCodeのバグを探る攻撃者にとって格好のターゲットになっています」と同氏は記しています。
攻撃手法
Askarによれば、脅威アクターはJupyterノートブック（計算ドキュメントの作成・共有に使うWebアプリケーション）を使用してリポジトリに拡張機能をインストールし、パブリッシャーの信頼チェックをスキップした状態で悪意のあるローカルワークスペース拡張機能をインストールできるとのことです。概念実証（PoC）において同氏は、ペイロードが実行されると新たにインストールされた拡張機能がGitHub APIトークンを取得し、開発者がアクセス可能なプライベートリポジトリを照会するクエリを実行して、返ってきた内容とトークンを出力すると述べています。
この脆弱性はデスクトップ版のVSCodeにも存在するとAskarは述べていますが、悪用するには脅威アクターが被害者にリポジトリをクローンさせ、webviewスクリプトのペイロードを含むノートブックを開かせる必要があるため、難易度は高いとのことです。「もちろん」と同氏は付け加えています。「webviewに別のXSS（クロスサイトスクリプティング攻撃）が存在し、被害者にそれを開かせることができれば、事実上コンピュータ上で完全なRCE（リモートコード実行）が可能になります。」
メールの中でAskarは、この脆弱性は「考えられる中で最も深刻なレベルに近い」と述べています。「インターネット上のどんなWebサイトでも、あなたをgithub.devのリンクにリダイレクトし、攻撃者がコードリポジトリの読み取りや変更を行うためのトークンを入手できる状態でした。人気ソフトウェアプロジェクトのメンテナーにリンクをクリックさせることができれば、そのプロジェクトに対して任意の変更を加えられた可能性があります。」
これが意味するのは、とEnderle氏は述べています。「開発者のエンドポイントを厳格かつ隔離されたゼロトラストのパラメーターで扱い始める必要があります。ベンダーの慢心に自分たちの安全を委ねることは、明らかにできないからです。」
この問題は、リンクのアクセス先を正確に把握していない限り、決してリンクを踏んではならないという原則を改めて裏付けるものだと、GitGuardianのプリンシパルデベロッパーアドボケイト、Dwayne McDaniel氏は述べています。
短すぎる通知
話はここから複雑になります。以前MicrosoftにVSCodeの脆弱性を開示した際の不満な経験——バグは修正されたものの、Askarはクレジットを与えられなかった——から、今回は新たな発見を公開する1時間前になってようやくGitHubに通知を行いました。MicrosoftはAskarが「暫定的な」修正と呼ぶ対応を実施しました。開発者がWeb版VSCodeでノートブックを開く際に確認ダイアログを追加し、コマンドによってtrusted publisherの要件をスキップできないようにするものです。
[関連記事: 責任ある情報開示が無償労働になるとき]
倫理的な問い
Askarの短い通知期間は、ある倫理的な問いを浮かび上がらせます。責任ある研究者は、脆弱性を公開する前にどのくらいの期間を置いてベンダーに通知すべきなのでしょうか。
現在、情報セキュリティの専門家の大多数は、通知を行わなければ脅威アクターがすぐに脆弱性を悪用できてしまうとして、事前通知は必須だという点で一致しています。さらに、適切な通知なしに公開した場合、研究者自身の評判を傷つけるリスクもあります。経験豊富な研究者は、パッチの作成と配布に少なくとも30日間の猶予をベンダーに与えることが多いです。
一方ベンダー側は、研究者の貢献に報いるためにバグバウンティプログラムを設けたり、既存のプログラムと提携したりすることが多いです。しかし残念ながら、研究者にクレジットを与えなかったり、脆弱性による被害の深刻度を過小評価したりするベンダーも少なくありません。実際、先月もMicrosoftと著名なサイバーセキュリティ研究者の間で、そうした疑惑をめぐる公開論争が起きています。
権力の不均衡
Askarの今回の発見についてコメントを求めたところ、Microsoftの広報担当者は次のように述べました。「セキュリティ研究コミュニティが当社の製品・サービス、そしてより広い技術エコシステムのセキュリティ強化において果たす重要な役割を高く評価しています。独立した研究者が自身の発見をいつ、どのように公開するかを決定することは理解していますが、報告された問題を迅速に評価し、適切なエンジニアリングおよびセキュリティ対応リソースを動員して、お客様の安全を守るための緩和策・ガイダンス・保護策をできる限り早く提供することに引き続き取り組んでいます。」
[関連記事: 脆弱性開示プロセスに欠陥はあるのか？]
ソフトウェアベンダーとの協調的な脆弱性開示（CVD）と完全開示の間にはバランスが必要だと、Askarは語っています。しかし同氏は、権力の不均衡が存在するとも指摘しています。「セキュリティ研究者は、ある問題に対して膨大な時間を注ぎ込み、優れた概念実証を開発し、問題を再現するための手順をすべて提供することがあります。そうした努力に対して、少なくとも自身のセキュリティ実績を高めるために使える謝辞、あるいは最善の場合には金銭的な報奨金を得られることを期待するのは当然のことです。」
しかし同氏はこう続けています。「セキュリティベンダーが約束を守らない場合、脆弱性を抱えたまま何もしないか、ブラックマーケットで売るかしたくないのであれば、公開開示はセキュリティ研究者に残された数少ない選択肢のひとつです。公開開示によってベンダーは問題を公式に認めざるを得なくなり、非公開のコミュニケーションよりもはるかに迅速な解決につながることが多いのです。」
このことが企業に問題をもたらすと、Enderle氏は述べています。「ベンダーの官僚主義が責任ある情報開示にペナルティを与えるようになれば、セキュリティコミュニティを遠ざけ、公開ゼロデイ情報の流出を招き、最終的にしわ寄せを受けるのはエンタープライズの顧客です。」
この記事はもともとInfoWorldに掲載されたものです。
