Google のバグ探し Project Zero チームは、情報開示延期の要請を拒否した後、GitHub Actions のインジェクション脆弱性の詳細を公開した。
この問題は、GitHub Actions によって実行時に解析される環境変数を設定できることに起因しています。Project Zero の開示情報によると、「ランナープロセスは標準出力に出力されるすべての行を解析してワークフローコマンドを探すため、実行中に信頼できないコンテンツを出力するすべての GitHub アクションは脆弱です。多くの場合、任意の環境変数を設定できると、別のワークフローが実行されるとすぐにリモートコード実行が発生します。」
この問題は7月に発見され、GitHubに報告されました。GitHubは脆弱性のあるコマンドを非推奨とする勧告を発行し、set-envGitHubadd-pathは問題の説明も公開しました。つまり、Project Zeroが投稿した情報はより詳細で例も含まれているものの、それほど大きな情報ではないということです。このセキュリティホールにはCVE-2020-15228が割り当てられ、深刻度は「中」と評価されました。
Project Zeroの研究者フェリックス・ウィルヘルム氏が指摘するように、修正は困難です。「ワークフローコマンドの実装方法は根本的に安全ではありません。」GitHubの解決策は、リスクのあるコマンドを徐々に削除することです。
GitHubは先月、 「本日からRunnerバージョン2.273.5では、コマンドadd-pathまたはset-envコマンドを使用すると警告が表示されるようになります。これらのコマンドの使用状況に関するテレメトリを監視しており、将来的には完全に無効化する予定です」と発表しました。ただし、これらのコマンドを削除すると、それらを使用するワークフローが機能しなくなりますが、そのまま残しておけば脆弱性は残るため、時間の経過とともにユーザーはこれらの機能から解放されていくでしょう。
GitHubは、DMCAのYouTubeダウンロードツールをフォークした開発者はBANされると警告...RIAAを打ち負かす方法を示唆
続きを読む
Project Zeroのタイムラインを見ると、GitHubの対応に対する不満が伺えます。通常、バグレポートはベンダーへの送信から90日後、または問題が解決された時点のいずれか早い方で公開されますが、これは延長されることもあります。
10月12日、Project ZeroはGitHubに対し、脆弱なコマンドを無効にするのにさらに時間が必要であれば「猶予期間を設けている」と伝えたと述べた。GitHubからの回答は、11月2日までの標準的な14日間の延長を要請するというものだった。
10月30日、Googleは次のように発表した。「返答がなく、期限が迫っているため、Project ZeroはGitHubの他の非公式な連絡先に連絡を取りました。返答は、問題は解決したとみなされており、予定通り2020年11月2日に公開できることが確認できたというものでした。」
この声明の意味するところは、投稿がさらに遅れる可能性があったということだが、その後 GitHub が「顧客に通知するため」にさらに 48 時間を要求したとき、Project Zero は「現在 104 日目 (90 日 + 14 日間の猶予延長) であるため、期限をさらに延長する選択肢はない」と述べた。
nCipher Securityのセキュリティ研究者、マーク・ペニー氏はTwitterでこう述べた。「この情報開示方法がGoogle以外の誰にとっても有益であるのか、私にはどうしても理解できません。今回のケースでは、Googleの研究者もGitHubもこの問題を修正する方法を知りません。そのため、脆弱なコマンドの廃止が至急求められています。しかし、その廃止が完了する前に、Project Zeroは概念実証コードと詳細情報を公開することに決めたのです。」
GitHub は問題を無視したわけではなく、むしろ安全でない機能を最終的に無効にしてユーザーに代替手段を提供するという措置を講じているため、ベンダーに迅速な修正策を出すよう圧力をかけるという一般的な意味では、情報開示のメリットは見いだしにくい。
GitHubにとって11月は幸先の良いスタートとは言えませんでした。2日目にはSSL証明書の期限切れによりサイトがダウンしてしまいました。Twitterでは多くの苦情が寄せられていましたが、あるユーザーは感謝すべき点を見つけました。「@github アセットの証明書が本日期限切れです… 中小企業でも大企業でも、誰にでも起こり得ることを教えてくれてありがとう。」®
