オープンソース流「広報戦略“虎の巻”」：オープンソースソフトウェアの育て方（2/4 ページ）

[Karl Fogel， ]

セキュリティ脆弱性の告知

　セキュリティ脆弱性の処理の仕方は、ほかのバグ報告の場合とは異なります。通常、フリーソフトウェアの世界では、物事をオープンにして誰にでも見えるようにすることが当たり前のことです。一般的なバグ報告の対応状況は、興味のある人なら誰にでも見えるようになっています。いつバグが報告されたのか、どのような議論がなされたのか、そして最終的にどのように修正されたのか。これらはすべて、知りたければ誰でも知ることができるわけです。

　セキュリティに関するバグの場合は、これとは異なります。セキュリティに関するバグが原因でユーザーのデータが漏えいしてしまう可能性もありますし、場合によってはコンピュータを破壊してしまうかもしれません。このような問題をオープンな場で議論してしまうと、問題があることを全世界に知らしめてしまうことになります。当然その中には、そのバグを悪用しようという人たちもいることでしょう。単に淡々とバグを修正してコミットしただけでも、バグの存在を世にさらしてしまうことになります（攻撃者の中には、公開されているプロジェクトのコミットログをチェックしている人もいます。変更内容を調べれば、変更前のコードにセキュリティ上の問題があることが分かるでしょう）。ほとんどのオープンソースプロジェクトでは、この開放性と秘密主義の対立に折り合いをつけるために同じような方針をとっています。その方針は、以下のようなものとなります。

1. 修正が完了するまではバグのことを口外しない。そして、バグがあったことをアナウンスすると同時に修正プログラムを公開する
2. 修正プログラムは、可能な限り迅速に提供する。そのバグが外部からの報告で発覚したものである場合は特に急ぐ必要があります。というのも、プロジェクトの外部の人間の中に少なくとも1人はその脆弱性を突く攻撃ができる人がいるということがはっきりしているからです

　実際のところ、この規則は標準化した手順としてまとめることができます。これらの手順について、以下のセクションで解説します。

• バグ報告を受ける

　当然ながら、各プロジェクトにはセキュリティバグの報告を一般から受け付けるための窓口が必要です。しかし、これは通常のバグ報告を受け付けるアドレスと一緒にはできません。というのも、通常のバグは誰にでも見えるようになっているからです。そこで、セキュリティ関連のバグ報告を受け取るためのメーリングリストを別途用意します。このメーリングリストのアーカイブは一般に公開してはいけません。また、参加資格は厳しく制限するべきです。そのプロジェクトに長くかかわっていて信頼できる開発者たちのみをメンバーに加えるようにしましょう。もし“信頼できる”の具体的な定義が必要な場合は、例えば“コミット権を得てから2年以上経過している”などといった条件を使用するといいでしょう。そうすれば、参加資格に関して“えこひいきしているのでは？”といった批判を避けることができます。このメーリングリストに参加しているメンバーが、セキュリティバグに対応するメンバーとなります。

　セキュリティ関連のメーリングリストについては、スパム対策やモデレートは行わないのが理想です。というのも、重要な報告がスパム扱いされてしまうと困りますし、たまたまその週末にすべてのモデレータがメールをチェックしなかったなどという理由で重要な報告に気付くのが遅れるというのも困ります。何らかのスパム対策ソフトウェアを使用するのなら、可能な限り緩やか目の設定にしておきましょう。重要な報告をフィルタリングしてしまうくらいなら、多少のスパムが混ざってしまう方がずっとましです。作成したメーリングリストをうまく活用するためには、そのアドレスを周知させる必要があります。しかし、このメーリングリストはモデレートされておらず、またスパム対策も甘いものです。従って、そのアドレスを宣伝するときには、アドレスを隠すために何らかの細工が必須となります。詳細は章3.技術的な問題のアーカイブでのメールアドレスの処理項で説明しています。幸いにも、アドレスを読みにくいものになどしなくてもアドレスを隠すことは可能です。Subversion Securityをご覧になった上で、そのページのHTMLソースを確認してみてください。

• 大至急それを修正する

　セキュリティメーリングリストに報告が来たら、次は何をすればいいのでしょう？　まずすべきことは、その問題の重大度（severity）と緊急性（urgency）を評価することです。

1. その脆弱性はどれくらい深刻なものでしょう？　悪意のある攻撃者が、そのソフトウェアを使用しているコンピュータを乗っ取ってしまえるほどのものですか？　それとも、ただ単に何らかのファイルのサイズが漏えいしてしまうというだけのものですか？
2. その脆弱性を突く攻撃の難易度はどの程度ですか？　スクリプトを使って誰でも攻撃できる程度のもの？　あるいはその場の状況を熟知している人が高度に頭を働かせても、ごくまれにしか成功しないもの？
3. 誰がその問題を報告してきたのですか？　この問いへの答えで脆弱性そのものの性質が変わるわけではありませんが、ほかにどれくらいの人がその問題に気づいている可能性があるかを推測できます。もしそのプロジェクトの開発者自身から報告されたのなら、少しだけ（本当に少しだけ）安心できます。恐らく、その報告者は他人にその問題を漏らしていないでしょうから。一方、もし [e-mail] とかいうアドレスからのメールで報告を受けたのなら、一刻も早く対応すべきでしょう。あなたにその問題を報告してくれた人は、あなた以外の人にもその情報を漏らしているかもしれません。あるいは報告を受けたときには既にその脆弱性を突いた攻撃を始めているかもしれません。

　ここで考えているのは、あくまでも緊急（urgent）と超緊急（extremely urgent）のどちらかというレベルの話であることに注意しましょう。たとえ今回の報告が既知の信頼できるところからのものであったとしても、それよりずっと前にほかの人が同じ問題を発見しているがただ報告していないだけなのかもしれません。緊急性が低いといえるのは、そのバグが本質的に深刻なセキュリティ問題を引き起こさないといえる場合のみです。

　ところで、さきほどの“[e-mail]”の例は、決して冗談ではありません。実際、このようにどこの誰だか分からないような相手からバグの報告を受けることもあり得ます。彼らは自分の身元を明かすこともないでしょうし、あなたの味方なのか敵なのかさえはっきりさせないでしょう。しかし、そういったことは関係ありません。あなたにセキュリティホールを教えてくれたということは、向こうはあなたに対して1つ貸しを作ったと考えているはずです。それに対して、誠意を持って対応する必要があります。

　まず報告してくれたことに対して感謝し、修正版を公式リリースする予定日を彼らに伝えるようにします。時には報告者側から日時を指定されることもあります。つまり、「バグが修正されているかどうかにかかわらず、○月○日になればこの問題を公表する」などどして暗黙の脅しをかけてくるようなものです。これは単なる弱い者いじめに感じられるかもしれませんが、恐らくその報告者が過去に経験したいやな思い出（せっかくセキュリティ問題を報告してやったのに、ソフトウェアの作者にまともに取り合ってもらえなかったなど）に基づく先制攻撃と考えた方が適切でしょう。

　いずれにせよ、報告者をいちいち怒らせている余裕などありません。結局のところ、もしそのバグが深刻なものだとしたら、その報告者はユーザーに問題を引き起こさせる方法を知っているということになります。彼の機嫌を損ねないよう丁重に扱いましょう。そうすればきっと相手もこちらを尊重してくれることでしょう。

　セキュリティバグの報告者としてほかによくあるのは、セキュリティの専門家です。彼らはソフトウェアのコードを監査するのを仕事にしており、ソフトウェアの脆弱性についての最新情報を追いかけています。この手の人たちは、バグを報告する側だけでなくバグ報告を受け取る側としての経験も豊富です。恐らくあなたのプロジェクト内のどのメンバーよりも経験を積んでいることでしょう。また、彼らの特徴としては、期日を指定してその日までの対応を迫り、期日がくればバグを一般に公表するというやり方があります。交渉次第で期日を引き延ばせるかもしれませんが、それは相手によります。セキュリティの専門家たちにとっては、報告先にまともに取り合ってもらうための唯一効果的な方法が期日を設定することなのです。彼らが期日を指定してきたとしても、それを失礼だとは思わないようにしましょう。それなりの理由があって続いている伝統なのですから。

　重大度と緊急性を判定し終えたら、実際の作業に取り掛かり始めます。修正をエレガントに行うか、それともとにかく素早く修正するのかのトレードオフになることもあります。このようなときのために、まず緊急性を判定したのです。セキュリティに関する修正についての議論は、当然セキュリティメーリングリスト内でのみ行います。また、問題の報告者がもし議論への参加を希望するなら、報告者もその議論に参加させましょう。そして、技術的な理由でそれ以外の開発者が参加することもあるかもしれません。

　修正内容をリポジトリにコミットしてはいけません。一般に公開するまではパッチ形式で管理しておくようにします。もし仮にそれをコミットしてしまったら、たとえログメッセージを適当に取り繕っていたとしても見る人が見ればその変更の意味するところを感づかれてしまいます。どこの誰がどういう目的であなたのリポジトリをチェックしているかなんて分かりません。

　コミットメールの送信をやめたとしても無意味です。まず、コミットメールの送信が突然止まったという時点で「何か怪しい」と思われてしまうでしょう。そしてコミットメールの有無にかかわらず、その内容はリポジトリのデータとして残されているわけです。修正の開発はすべてパッチ形式で行い、パッチは隔離された場所で管理します。そのバグの対応をしている人たちだけが知っている個別のリポジトリなどがいいでしょう（ArchやSVKといった中央管理型ではないバージョン管理システムを使用しているなら、完全にバージョン管理された環境で作業を進めることができます。バグへの対応中は、外部からはリポジトリにアクセスできないようにしておけばいいのです）。