今週前半、VirualBoｘの権限昇格につながるゼロデイ脆弱性の詳細がGitHub上で公開されました。これを明らかにしたのは、ロシアの独立系セキュリティ研究者Sergey Zelenyuk氏です。彼は、セキュリティリサーチとバグ報奨プログラムの現在の状況に対する抗議の意味で、この脆弱性をベンダーに通知することなく公開しました。
彼が懸念していることの一部は事実に基づいており、さらなる議論が必要だと私は考えています。彼の意見は、バグハンターのコミュニティの大方の見解を反映していると思います。
Zelenyuk氏は、彼の考えを以下の3つのポイントとして示しています。
1.ベンダーのパッチ配布が遅すぎる
大手ベンダーは、脆弱性の評価と修正に時間がかかりすぎる傾向がありますが、多くの研究者らはこれを容認しています。
Googleの脆弱性発見チーム「Project Zero」が掲げる「90日後公表ポリシー」（脆弱性をベンダーに報告後90日が経過したら公表するというルール）によって、一部のベンダーのパッチリリースは早まりました。実際に、Black Hat 2018では、Parisa Tabriz氏がこのことを裏付ける有望な統計データを発表しました。その中で最も印象的だったのは、Googleの研究者からの脆弱性の報告のうち98%が90日以内に修正されたのに対し、このような期限付きの公表ルールが存在する前は、わずか25%であったということです。
Project zeroとの明確な因果関係はないものの、Tabriz氏はパッチ頻度を大幅に上げ、レポートへの応答時間を短縮している大手ベンダーについて、匿名で言及しました。
残念ながら、このような企業は少数派であり、Zelenyuk氏がコメントしたように、重大なバグを修正するために6か月もかかることは珍しくありません。この問題には、複数の要因が絡み合っています。その1つには、個人研究者と彼らがコンタクトする企業との間に、多大な力の不均衡があることです。この力の差を盾に、無反応、あるいは高圧的な態度を取るベンダーも存在します。
もう1つ考慮すべきこととして、小規模なソフトウェア会社を吸収する大手企業のほとんどは、買収の都度セキュリティチームの整備を行わなかったり、全社共通のセキュリティプロセスを実施しない傾向があります。一般的に大手ベンダーは、広範な製品ポートフォリオを持つために、他のベンダーよりも対応までの時間を長く見積もっています。しかし、影響力のあるベンダーには、より迅速な対応を求めるべきであると私は考えます。
2.バグ報奨金プログラムに一貫性がなく信用できない
私はバグ報奨金プログラムを高め、お金まで貰えることを好ましく思っています。私自身は良い経験気に入っており、強力な賛同者です。私も数年以上にわたり、10数件を超えるプログラムで報奨金を受け取っています。そして、安全なシステムの提供に貢献しながら、自分のスキルををしているとは思いますが、このようなプログラムの運営方法やセキュリティに与える影響については、数多くの不満があります。
バグ報奨金レポートを受け取り、レビューを行う一部の担当者からは、このプログラムを、セキュリティ向上のための協力的なプロセスではなく、むしろ敵対的なゲームのように捉えているという印象を受けることがあります。信頼できる脆弱性レポートが、バグのクラスや分野が対象外という理由で、調査も行われずに参考情報または無効な情報と判断されてクローズになることもよくあります。
たとえば、ROBOTのようなミドルボックスのHTTPS実装の脆弱性の場合では、どのようなミドルボックスが使用されているか、あるいはそれに最新のパッチが適用されているかといったことを知る方法がないままに、脆弱なWebサイトを発見するのが一般的です。私もこのような脆弱性を報奨金プログラムに通報したことが何度かあります。「SSLの脆弱性」は、報奨金の対象外であったことは知っていましたが、脆弱な製品の特定と公開に協力できればよいと思ったからです。
このようなレポートでは、脆弱性の内容を簡潔に説明するとともに、報奨金は期待しておらず、ただ脆弱性を含むデバイスのベンダーに通知して公開に向けた支援を行いたい旨を示しています。しかし、その返事として、「申し訳ございません。この分野は報奨金の対象ではありません。次回また頑張ってください」というコメントともに、このレポートはクローズされたという通知が送られてくるのです。
一部の企業は、バグ報奨金プラットフォームを、脆弱性レポートを共有するための唯一のコミュニケーションツールにしています。報奨金プログラムに、「ベンダーからの明示的な許可なしにレポートを第三者と共有した場合、研究者は処罰される」ことを規定する条項が含まれている場合、このことは問題となります。ベンダーはバグ報奨金プログラムを利用して、研究者たちがどうしようか決めかねている間、沈黙させておくことができます。
その結果、研究者が、報奨金を貰うか、ユーザーの保護に一役買うかを選択しなければいけない場面も出てくるでしょう。この問題のもう1つの側面は、一部のベンダーが第三者を雇って報奨金プログラムを運営させたり、レポートをふるいにかけさせたりしていることです。上記のROBOTの例で、対象外との判断で返されたレポートが、ベンダーのセキュリティチームの目に触れていない可能性もあるのです。
3.マーケティングチームがセキュリティリサーチを過剰宣伝している
情報セキュリティ会社の有力なマーケティングツールとして、名前の付いた脆弱性や大げさなカンファレンストークが使われるようになりました。特定の脆弱性に単なる番号ではなく名前を付けることにメリットがあることは間違いありません。しかし、多くの場合、このプロセスは、実際の脅威からセキュリティチームの注意をそらし、セキュリティのためにはなりません。（badlockのケースを覚えていますか？）
マーケティング主体のセキュリティリサーチの問題がカンファレンスに広がっています。また、イベントでは「新しい」リサーチに重きが置かれがちです。このことから、一部のベンダーは、脆弱性の公開をセキュリティ上最適なタイミングではなく、カンファレンスのスケジュールを基に調整しようとします。
トレードショーで周りをあっと言わせたいがために、セキュリティフィックスの配布を遅らせれば、その脆弱性の影響を受けるすべての人に不利益をもたらします。
これまで折り合いの悪かったソフトウェアベンダーとホワイトハッカーの関係は、かなり良くなってきたものの、まだまだ前途多難です。とにかく、私はベンダーに、研究者とのやりとりを透明にし、バグハンターがベンダー側を助けるつもりであることを覚えておいて欲しいと思います。報奨金を支払う企業も、バグを報告している人々は、投資への見返りが保証されていないにも関わらず、彼らの時間を投資してくれていることを忘れないでください。
もしあなたが研究者側の人間であれば、あなたが行った調査を大局的に捉え、あなたの発見が与える実際の影響を鑑みて、ベンダーに対して寛容になってみましょう。そして最後に、もしあなたが、「利用可能なパッチが準備されているとカンファレンスがつまらなくなる」などと本気で考えていて、注目を集めるために脆弱性の公開を遅らせようとするくらいならば、登壇自体をやめることを考えてください。
