現在、当サイト「mozilla.org 日本語版」の和訳文書は更新されておらず、mozilla.org の原文 よりも内容が古くなっている可能性があります。ご不便をお掛けしますが、最新の情報は原文をご確認ください。



Mozilla セキュリティバグの取り扱い

バージョン 1.1
2003 年 2 月 11 日

重要 : Mozilla 関連のセキュリティ脆弱性を発見した人はだれでも security@mozilla.org へメールを送ってそれを報告することができます。また、報告するべきです。詳しい情報は、このドキュメントの続きを読んで下さい。

イントロダクション

Mozilla セキュリティ脆弱性解決のための Mozilla プロジェクトの取り組みを向上させるため、mozilla.org は、Mozilla のセキュリティ関連のバグの取り扱いに関して、より正式な取り決めを作成しています。まず、mozilla.org は、報告された Mozilla のセキュリティ脆弱性の調査・解決をコーディネートする第一の責任を持つ、セキュリティモジュールオーナーを指名しています。セキュリティモジュールオーナーには、この作業を手伝う 1 人以上の共同作業者がいます。同時に、mozilla.org は Mozilla の貢献者やその他の人たちが Mozilla のセキュリティ脆弱性解決の取り組みに参加できるように、より大きな「Mozilla セキュリティバググループ」も設置しています。このドキュメントは、この新しい組織体制がどう働くか、セキュリティ関連の Mozilla バグの報告がどう取り扱われるかについて説明しています。

この新しい体制の焦点は、Mozilla コードの問題に起因する、現存のセキュリティ脆弱性解決の取り組みだけに制限されているということに注意してください。この作業は、明らかに多くの同じ人たちが両方の活動に関わっていますが、新しいセキュリティ機能(暗号化ベースのものやその他のもの)を Mozilla に追加する開発者の作業とは区別されます。

背景

セキュリティ脆弱性は他のバグとは違います。なぜなら、それらがとても重大な影響を及ぼす可能性があるからです。ユーザの(財務情報を含む)個人情報がむき出しになったり、データが破壊されたり、他のシステムを攻撃するプラットフォームとしてユーザのシステムが使われたりする危険性があります。従って、セキュリティ関連のバグがどのように取り扱われるかについて、特に、そういったバグに関する情報がどの程度公開されているのかについて、強い関心が持たれています。

Mozilla プロジェクトは、公開のソフト開発プロジェクトですから、私たちは公開性へ向かう本質的な傾向を持っています。特に、セキュリティ脆弱性に関するすべての情報は、分かったらすぐに公開されるべきだと思っている人たちの関心を理解し、同意しています。そうすれば、ユーザは自己防衛のために迅速な手段を講じるでしょうし、それらの問題は開発者から最大限の関心を得て、可能な限り早急に修正されることができます。

同時に、Mozilla プロジェクトは、Mozilla のコードを自分たちの製品販売に使っている(または使う予定のある)組織から、多くのコードや開発者の時間の貢献を受けています。それらの製品のいくつかは多くのエンドユーザに使われ、その人たちの多くは、アップグレードや最近のセキュリティ修正のチェックをほとんど行わないでしょう。私たちは、あまり早まって功績の詳細を公開してしまうことが、潜在的な攻撃者に短期的な有利性を与えてしまうと思っている人たちの関心を理解し、同意しています。そのような攻撃者は、大部分のエンドユーザがその問題の存在に気付く前に、それを利用できてしまうからです。

私たちは、どちらの関心も正しいと思っていますし、どちらもできる限りの解決に取り組む価値があるものです。私たちは、Mozilla プロジェクトがセキュリティ脆弱性の報告をどう取り扱うかに関して、妥協案の作成を試みました。これは、バグの公開に関してどちらの疑問を持つ人に対しても正当化できる妥協案だと思っています。

一般方針

mozilla.org は、セキュリティ脆弱性に関するバグ報告の取り扱いについて、次の一般方針を採用しています。

  • セキュリティバグの報告は、特別なものとして扱われ、「普通の」バグとは異なる処理をされることがあります。特に、mozilla.org の Bugzilla システムは、セキュリティ脆弱性に関するバグの報告を「セキュリティ機密」としてマークされることを認め、そのようなバグの報告には専用のアクセス管理機能が特別に用いられます。ただし、セキュリティバグは(「セキュリティ機密」のフラグが削除されて)普通のバグに戻ることもあります。そのような場合、アクセス管理制限はもはや効力がありません。
  • セキュリティバグに関する完全な情報は、上で説明した Bugzilla アクセス管理制限を使って、既定のグループのメンバーに制限されます。ただし、そのグループは必要に応じて適切に拡大されることもあります。
  • 上で述べたように、セキュリティバグに関する情報は、しばらくの間機密にされることがあります。それがどのくらいの期間になるのか、あらかじめ決められた期限はありません。ただしこれは、バグを報告した人がバグの解決に取り組むための活動(がもし行われれば)を見ることができ、バグの報告を公開の審査に開示できる権限を持っているという事実によって相殺されます。

これ以降のセクションでは、これらの一般方針がどのように実行されているのかについて、さらに詳しく説明しています。

セキュリティバグ取り扱いのための組織体制

私たちは、一般的な Mozilla プロジェクト活動の取り扱いと同様に、Mozilla セキュリティ脆弱性の調査・修正を組織しています。そこには、セキュリティモジュールオーナーや、彼らの共同作業者としての役割を果たせる、活動的な貢献者たちの小さな中心的グループ、それほど活動的ではない貢献者たちも含んだより大きなグループ、そして、その時々に関わってくるその他の人たちがいます。他の Mozilla プロジェクトと同じように、Mozilla のセキュリティ関連の活動における参加は、個人的なボランティアと、Mozilla に関わるさまざまな企業の従業員やその他の団体の両方に開かれています。

Mozilla セキュリティモジュールオーナーと共同作業者

Mozilla セキュリティモジュールオーナーは、他の Mozilla モジュールオーナーと同じレベルの権限や責任を持っています。また、他の Mozilla モジュールオーナーと同じように、mozilla.org スタッフは、セキュリティモジュールオーナーの作業を監督し、何らかの理由で必要なときには新しいモジュールオーナーを選びます。

Mozilla セキュリティモジュールオーナーは、セキュリティ脆弱性の調査・解決に自分の共同作業者としての役割を果たす人を選ぶ作業を mozilla.org スタッフとともに行います。その共同作業者となる人は、セキュリティバグ関連のありとあらゆる活動の監督とコーディネイトについての責任を共有します。

Mozilla セキュリティバググループ

Mozilla セキュリティモジュールオーナーと共同作業者は、Mozilla セキュリティバググループの中核を形成し、そのグループのメンバーを完成するために他に数人を選びます。Mozilla セキュリティバググループの各メンバーは、「セキュリティ機密」とマークされたすべての Mozilla バグへのアクセスを自動的に許可されます。Mozilla セキュリティバググループの メンバー は、主に以下のグループから引き抜かれます。

  • セキュリティ開発者(すなわち、自分のバグがよくセキュリティ関連として選ばれていたり、セキュリティ関連のバグを自分に割り当てている人)や、それらのバグの QA コンタクトであるセキュリティ QA のメンバー
  • 重要な Mozilla セキュリティ脆弱性の発見に優れた実績を持つ「手柄ハンター」
  • Mozilla ベースの製品を積極的に配布している、各方面の企業やグループの代表者
  • スーパーレビューワやドライバー

(Bugzilla の管理人も、主に mozilla.org を通じてホストされているすべての Bugzilla データをすでに熟知しているという理由から、Mozilla セキュリティバググループに技術的に参加します。)

Mozilla セキュリティバググループは、グループ内の全員が購読する非公開のメーリングリスト security-group@mozilla.org を持っています。このメーリングリストは、以下で述べるように、グループの方針や新メンバーの追加について議論するためのフォーラムとしての役割を果たします。さらに、mozilla.org は 2 番目によく知られているアドレス security@mozilla.org を運営していて、ここにはセキュリティ グループに参加していない人がセキュリティバグの報告を投稿できるようになっています。このアドレスに送られたメールはセキュリティモジュールオーナーと共同作業者に届きます。彼らは Bugzilla が受け入れた情報の投稿に責任を持っており、バグの趣旨や重要度、潜在的な利用のリスクが保証されたとき、そのバグを「セキュリティ機密」としてマークします。

その他の関係者

上述のセキュリティバググループの常任メンバーの他に、セキュリティバググループの活動に参加し、機密とされるセキュリティバグ レポート以外にアクセスできる、別の 2 つのカテゴリに入る人たちがいます。

  • セキュリティバグを報告した人は、そのバグが「セキュリティ機密」とマークされても、そのバグに関係するすべての Bugzilla 活動へのアクセスを続けます。
  • その他の人たちは、(特定のセキュリティバグへのアクセスを許されている人の)誰かがその人をそのバグの CC リストに加えれば、そのバグへのアクセスを許可されます。

従って、セキュリティバグを報告した人は、実質的にその特定の脆弱性を調査・修正する作業を行う人たちの全体的なグループの一員になり、その他の人たちは、もし理にかなえば、同じように容易に協力に招待されます。

Mozilla セキュリティバググループの拡大

前述のように、Mozilla セキュリティモジュールオーナーは、Mozilla セキュリティ脆弱性の調査・解決をコーディネイトする中心的な作業を共有するために、1 人以上の共同作業者を選ぶことができます。そして、どうすればこの作業を自分たちのあいだで最も効果的に共有できるかという、いくつかの合意に基づく基本原則を作るために、彼らとともに作業を行います。他の Mozilla モジュールと同じように、私たちはこの主要グループ(モジュールオーナー+共同作業者たち)を小規模のままにしておくつもりです。また、そのメンバーは、頻繁にではなく mozilla.org スタッフとの協議の後にだけ変更されるべきです。

また、セキュリティモジュールオーナーと共同作業者は、初期のセキュリティバググループを構成するために mozilla.org とともに作業を行います。私たちは、Mozilla セキュリティバググループが、セキュリティモジュールオーナーと共同作業者たちの主要グループよりも当初は非常に大きくなり、時間が経つにつれてさらに成長するだろうと思っています。新しいメンバーは次のようにして Mozilla セキュリティバググループへ加えられることができます。

  • 新しい人たちはセキュリティバググループへの参加を申し込むことができ、あるいは既存メンバーからスカウトされることもあります。参加希望者には、既にセキュリティバググループに入っていて、自分の保証人になり、メンバーへ推薦してくれることに同意している人がいなくてはなりません。推薦は「保証人」がセキュリティバググループの非公開メーリングリストへメールを送ることによって行われます。
  • 希望者のメンバーへの推薦は、それから数日間検討され、そのあいだ、セキュリティバググループのメンバーはその人の参加に賛成か反対か自由に意見を言うことができます。
  • この期間の終わりに、一般的にはセキュリティバググループからの、特にモジュールオーナーの共同作業者からのフィードバックや異議をもとに、セキュリティモジュールオーナーは参加者を受け入れるかどうかを決定します。もしセキュリティバググループの他の人がモジュールオーナーの決定に異存があるときは mozilla.org スタッフに訴えることができ、そのスタッフが最終的な決定を下すことになります。

Mozilla セキュリティバググループのメンバー選定基準は次のようになっています。

  • 希望者は既にグループに参加している人たちから信頼されていなければなりません。
  • 希望者はグループへ参加を希望するにあたって確かな目的を持っているべきです。
  • 希望者は何らかの方法でこのグループの活動の価値を高めることができなくてはなりません。

実際には、長期にわたって特定の人物が頻繁にセキュリティ機密バグの CC リストに加えられるような場合、その人はセキュリティバググループへの参加を勧められるよい候補者となります。(前述のように、一度セキュリティバググループへ加えられると、それぞれのバグの CC リストに明記される必要がある場合を除いて、その人はセキュリティ機密とされるすべてのバグへのアクセスを自動的に認められます。)

注意してほしいことは、私たちは、新しい人がセキュリティバググループへ比較的容易に参加できるようにするつもりですし、グループの規模を任意の人数に制限してはいませんが、まったく上限なしにグループを拡大したくはありません。私たちは、新規の申し込みを断るか、(必要に応じて適切な場合)セキュリティバググループの既存メンバーを解任し、新しいメンバーに席を譲ることによって、メンバーを適度な人数に抑える権利を留保しています。

セキュリティ脆弱性の公開

セキュリティモジュールオーナー、共同作業者、Mozilla セキュリティバググループの他のメンバーは、公式な守秘義務契約やその他の法的書類への署名を求められることはありません。しかし、私たちはグループのメンバーに対して次のことを強く期待しています。

  • Mozilla セキュリティバググループのメンバー以外の人、あるいはバグの解決に関わりのない人に、セキュリティバグの情報を公開してはいけません。ただし、Mozilla セキュリティバググループのメンバーが Mozilla をベースとした製品のディストリビューターに雇われていて、そのメンバーがディストリビューターとのあいだでそれらの情報を共有するといった場合を除きます。これらの情報は、知るべき必要がある関係者の中でのみ、知るべき必要がある範囲に限って共有されることを前提に提供されるもので、組織が一般に機密資料を扱うのと同じように区別、処理されます。
  • ニュースグループのような公開のフォーラムに功績の内容を投稿してはいけません。
  • バグの CC 欄に加える人には注意してください。(セキュリティバグで CC とされたすべての人は、完全なバグ・レポートへアクセスする可能性があるためです)

セキュリティバググループにバグが持ち込まれたとき、グループのメンバー、バグの報告者、そのバグに関係する他の人は、ユーザに対して直ちに警告を出すのが適当かどうか、それはどのような言葉で表現されるべきかを、バグに寄せられたコメントかメーリングリストを通じて、総意によって決定します。この警告の目的は、

  • Mozilla のユーザやテスターに、自分たちが使用しているバージョンにおける潜在的なセキュリティリスクと、それらのリスクを軽減するためにできることについての情報を提供し、
  • それぞれのバグに対して、その他のディストリビューターやその顧客がリスクにさらされずに、ディストリビューターが(修正が得られる前に)即座に公開できる情報の量を明らかにすることです。

典型的な警告は、影響を受けるアプリケーションやモジュール、バージョン、代替策(たとえば JavaScript を無効にする)を記載します。グループが警告の発表を決めたら、モジュールオーナー、共同作業者、指名された他の数人が 既知の脆弱性のページ(この情報に関する信頼できる情報源です)にメッセージを投稿し、このメッセージと同じものを適当なメーリングリストと(あるいは)ニュースグループ(たとえば netscape.public.mozilla.announce と(あるいは)この目的のために特別に設置された他のいくつかのニュースグループ/メーリングリスト)へ送ります。自分たちのユーザに脆弱性の存在を知らせたい Mozilla ディストリビューターは、「既知の脆弱性」ページから得たあらゆる情報を、自分たちの Web サイト、メーリングリスト、リリースノートなどに再投稿するでしょう。ただし、そのバグに関するどんな追加的な情報も公開すべきではありません。

セキュリティバグの元の報告者は、いつそのバグの報告が公表されるかを決定することができます。情報開示は、そのバグの「セキュリティ機密」指定を解除することによって行われ、それ以降そのバグは普通のバグに戻ります。私たちは、この権利をバグの報告者に投資することが、本当に事実を認めることだと思っています。セキュリティバグの報告者が、Mozilla プロジェクトと関連のない外部のチャンネルにこのバグに関する情報を投稿し公表するのを止めることはできません。(しかし実際には)そのようなことをせず、代わりに標準的な Bugzilla プロセスを通じたバグの報告を選ぶことによって、バグの報告者は Mozilla プロジェクトへ積極的な協力を行っています。従って、バグの報告者が関係のある Bugzilla データをいつ公開するか決められなければならないのは、当然のことなのです。

しかし、私たちは、Bugzilla を通じてセキュリティバグを報告するすべての個人・組織に、以下にあげる任意のガイドラインに従うようお願いします。

  • セキュリティバグを誰もが読めるようにする前に、非公開の Mozilla セキュリティバググループ メーリングリストにメールを送り、グループに数日間情報を提供してください。
  • 不当に長期にわたってセキュリティ機密カテゴリにバグを置かないようにしてください。
  • Mozilla ディストリビューターが、ユーザに新しいリリースを配布するなど、適度な追加期間、セキュリティ機密カテゴリにバグを置いておく合理的な必要があるときは、ご理解・ご協力をお願いします。(この点を考慮した上で、すべての Mozilla ディストリビューターがセキュリティバググループに代表者を持っている場合、バグがセキュリティ機密カテゴリに残っていたとしても、影響を受けるすべてのディストリビューターは情報を提供され、適切な行動をとることができます。)

セキュリティモジュールオーナーは、セキュリティバグの報告が調査されて適当な時期に公開され、そのようなバグ・レポートが Bugzilla データベースに未調査・非公開のまま残らないことを保証する、一番の責任を負った人です。セキュリティバグに関する情報を公開するかどうか、いつ公開するのかといった議論が生じた場合、セキュリティバググループは、メーリングリストを通じてこの問題を議論し、意見の一致を試みます。必要に応じて mozilla.org スタッフが「上告裁判所」としての役目を果たします。

バグ・レポートの複写についての最終点 : 複写とされたセキュリティバグは、公開が憂慮される限り、別途熟慮されます。従って、たとえば、特定のセキュリティ脆弱性が最初に報告され、それと同じものが無関係に他の人から再び報告された場合、それぞれのバグ報告者は自分たちのバグを公開するかどうかのコントロールを持ち続けますが、彼らの決定は他の人が報告したバグの公開には影響を及ぼしません。

この指針の変更

この指針は確定したものではありません。メンバー、情報開示、あるいはこの指針で扱われているその他あらゆる問題をめぐって生じる議論は、非公開のセキュリティバググループ メーリングリスト上での議論を通じて、Mozilla セキュリティモジュールオーナー、共同作業者、他のセキュリティバググループのメンバーのあいだの合意によって解決されることができるということが私たちの願いです。

Mozilla プロジェクトの問題と同じように、mozilla.org スタッフがこの指針を変更する最終的な権限を持っており、あらゆる意見が考慮されていることを保証するために、公開の Mozilla コミュニティに関わっている様々な関係者と協議したあとにのみ、指針の変更を行います。