【翻訳】ASan Nightly Project の紹介

この記事は、2018 年 7 月 19 日付で Mozilla Security Blog に投稿された Introducing the ASan Nightly Project （筆者：decoder）の翻訳です。この翻訳は公式なものではありません。詳しくは こちら をご覧ください。

---

ユーザの手元へ安定かつ安全な Firefox を確実に届けるため、 多くの Mozillian が長い時間をかけて日々テストを行っています。 しかし、残念なことにバグの無いプロダクトなど存在しないため、 どれほどテストに力を注いでも時としてブラウザはクラッシュしてしまいます。 実際にクラッシュレポートを調査してみると、 中には古典的なセキュリティバグ（解放後使用に代表されるメモリ破壊など）に見えるものもあります。 しかし、そのようなレポートから得られるデータは、 それ単独では何も意味をなさない程度に不十分（つまり、開発者が問題を特定・修正するのに十分でない）なことがしばしばです。 この傾向は、解放後使用といったメモリ破壊の問題において、 原因となるアクセス違反が起きてから実際のクラッシュが起きるまでにかなり時間が空くケースで特に顕著です。

Mozilla は結合テストとファジングを自動化していますが、そのプロセスで AddressSanitizer (ASan) を使用しています。 ASan はコンパイル時に組み込むツールであり、ここ 5 年間で大きな成果を挙げてきました。 解放後使用を例にすると、ASan はメモリのアクセス違反が起きたタイミングのみならず、 そのメモリを以前解放した場所も同時に報告してくれるため、 通常のクラッシュレポートよりも ASan は開発者にとってより有益な情報を提供してくれます。

Nightly のテストで ASan の恩恵をより得られるよう、私達は両者を ASan Nightly Project に統合することにしました。 特殊な ASan レポータアドオンを組み込んだ ASan Nightly ビルドを独自に作成し、 アドオンが ASan のエラーを検知・収集して Mozilla に送信できるようにしました。 このプロジェクトは既に実環境へ展開されており、 実際に見つかった ASan エラーのレポートを利用して、 再現の難しい問題も特定・修正できるようにしています。 現在は Linux 版ビルドにのみ導入していますが、Windows 版と Mac 版のビルドに対しても鋭意取り込んでいます。

当然ながらこのアプローチには欠点があります。 ASan の有無はコンパイル時間にはさほど影響を与えませんが、 解放後使用を検知するには ASan が解放済みのメモリを保持しておく必要があるため、 （既に量の多い）メモリ使用量がさらに増大するにつれて、ブラウザの実行時間がより長くなってしまうのです。 したがって、ASan Nightly ビルドを動かすには十分な量の RAM が必要となり（最低 16 GB 以上を推奨）、 またメモリを解放するために 1 日に 1 ~ 2 回ブラウザを再起動させる必要があります。

しかし、新しい Firefox 環境での web ブラウジングをいとわないのなら、 あなたはバグバウンティの報奨金を受け取る資格があるかもしれません。 あなたの Firefox から自動的に送信されるレポートは、 Bugzilla に報告されるテストケース無しの bug と同じように扱われます。 すなわち、その問題が 1) 適切なセキュリティバグであり、かつ 2) Mozilla の開発者によって修正可能な場合、 バグを報告したあなたにバグバウンティの報奨金が支払われます（Mozilla Bug Bounty Program の規則はすべて通常通り適用されます）。 このプロジェクトに参加してレポートを自分名義のものにする場合は、 Bug Bounty のセクションをよく読んだ上で、設定項目を正しくセットしてください。

このプロジェクトが成果を挙げるためには、十分多くの人がこのプロジェクトに参加してもらう必要があります。 参加規約を理解していただき、是非あなたも参加していただけることをお待ちしています。

Mozilla web セキュリティバウンティプログラムの刷新

この記事は、2017 年 5 月 11 日付で Mozilla Security Blog に投稿された Relaunching Mozilla’s Web Security Bounty Program （筆者：April King）の翻訳です。この翻訳は公式なものではありません。詳しくは こちら をご覧ください。

---

この度 Mozilla は web セキュリティバグバウンティプログラムを刷新し、 web セキュリティバグの報奨金における透明性を向上させました。

歴史

バグバウンティプログラムは何年も前に Netscape が 初めて 創設したものですが、Mozilla は 2004 年 8 月に バグバウンティプログラムを開始しました。 当時は Linspire, Inc. と Mark Shuttleworth から資金提供を受け、 Firefox と他の Mozilla ソフトウェアで見付かった重大なセキュリティ脆弱性に対して $500 を支払っていました。 現在のバグバウンティでは 金額が 6 桁に達する こともあるため、当時の金額は牧歌的に見えるかもしれませんが、 別の視点ではセキュリティバグの発見に対するテクノロジー企業の姿勢が大きく前進したとも見ることもできます。

それから 6 年後の 2010 年 12 月、 Mozilla は web サービスにバウンティプログラムを導入した最初の会社の 1 つとなりました。 報奨金額の幅は $500 から $3000 と大きく前進でしましたが、当時は web セキュリティの状態改善に焦点を合わせていました。

最初に報奨された web セキュリティバグ（addons.mozilla.org の XSS 脆弱性）から現在に至るまで、 自身の専門性を私たちのユーザの保護に役立ててくださった世界中のバグハンターに、延べ数十万ドルをお支払いしてきました。

問題と解決策

バグバウンティプログラムの運用は、特に Mozilla のような企業にとっては常に困難が伴います。 これまで約 20 年の間 web を支え続けてくれたスタッフやコントリビューターがいることに加え、 私たちの web サイトの種類は飛躍的に増えてきました。 www.mozilla.org から www.bugzilla.org や arewefastyet.com に至るまで数多くありますが、 これらのサイトの中には Mozilla のオペレーションに対して 他のものよりも 遥かに大きなリスク を抱えています。

そして問題はこのリスク特性をバグハンターに説明する際に生じます。 Bugzilla における限定的な SQL インジェクションは、 Observatory での XSS 攻撃やコミュニティブログでのオープンリダイレクタとは Mozilla に対するリスクが異なります。 しかし、バグハンターにとってはリスクの度合いに興味がないことがしばしばです。 彼らが知りたいことは、純粋にそのサイトのバグが報奨対象かどうかと実際に支払われる金額です。

概ね報奨対象の web サイトは合理的にリスト化されていると思いますが、実際の支払金額はケースによって異なります。 さらに、リストに明示的に載っていないサイトのバグに対する金額の判断はより難しくなります。

金額がバグハンターの期待と同等、もしくは超えるようであれば何も問題ありません。 しかし期待を下回ってしまった場合、バグハンターの方はがっかりしてしまうかもしれません。 さらには、特定のサイトに対して金額の例外を設けてしまうと、 他にも例外があるのではと期待させてしまう可能性があります。

現在

そこで私たちは先のような多くの問題を解決するべくバウンティプログラムを刷新し、 同時に報奨対象となる web サイトとバグの種類を増やしました。 さらに、それぞれのバグと web サイトの種類に対応する支払金額をリスク特性に基づいて 明示的にリスト化しました。

（詳しくは 表の全体を 参照してください）

明確で直感的な支払金額の表を作成したことで、 バグハンターの方々は報奨金が受け取れると分かっているバグの発見に時間と労力を注げるようになり、 前もって実際の支払金額を知ることもできます。 加えて、バグバウンティの Hall of Fame に登録されるバグの種類も拡大しています。 これらのバグに金銭的な報酬はありませんが、 バグハンターによる web の安全性に対する功績を広く感謝する私たちなりの方法として行っています。

私たちの ロゴ から 製品 に至るまで、Mozilla は公開性に自負を抱いている企業です。 報奨金額に対する公開性は世の中でまだ進んでいない領域ですが、 今回の刷新によって web 全体におけるバグバウンティプログラムの公開性向上に貢献できることを願っています。

web バグバウンティプログラムに既に貢献していただいている皆さんには、 この仕組みが皆さんの労力を集中させることに繋がれば幸いです。 初めて間もない皆さんには、ぜひ一緒にインターネットをより安全な場所にしていきましょう！

【翻訳】CA Certificate Policy バージョン 2.4 リリース

この記事は、2017 年 4 月 4 日付で Mozilla Security Blog に投稿された Mozilla Releases Version 2.4 of CA Certificate Policy （筆者：Kathleen Wilson）の翻訳です。この翻訳は公式なものではありません。詳しくは こちら をご覧ください。

---

私たち Mozilla は Mozilla’s CA Certificate Policy のバージョン 2.4.1 をリリースし、 Mozilla 製品に同梱されている ルート証明書を所有する 認証局（CA） に対して、要件に関する今回の変更点などを CA Communication として通知しました。 Network Security Services (NSS) とは、セキュリティ機能を持ったクライアント・サーバーを開発する際に、 クロスプラットフォームなアプリケーションとして開発できるよう設計された、 オープンソースのセキュリティライブラリ群です。 Mozilla’s CA Certificate Program は、 この NSS にルート証明書を追加する際の手続きを運用する役割を担っています。 NSS のルート証明書は Firefox ブラウザーといった Mozilla 製品のみならず、 他の企業やオープンソースプロジェクトが様々なアプリケーションで利用しています。

Mozilla’s CA Certificate Policy における今回の改訂内容は以下の通りです。

• 監査報告書に加え、証明書ポリシー（CP）と認証局運用ポリシー（CPS）を Mozilla へ毎年送付すること
• 2017 å¹´ 6 月 1 日より、監査報告、CP、CPS は英語で提示すること（必要に応じて翻訳すること）
• すべての提出資料にオープンなライセンスを付与すること（詳細はライセンスの選択肢と条項を参照）
• Mozilla’s CA Certificate Policy バージョン 2.4 から Common CCADB Policy と Mozilla CCADB Policy を参照するように
• 新しい Common CA Database (CCADB) により、CCADB に関して今まで暗黙だった期待事項を明文化
• 受理される監査基準の一覧を更新
• OCSP レスポンスに関する要件を追加
• 証明書のシリアルナンバーに対して 64 ビットのエントロピーを要件として指定

Mozilla’s CA Certificate Policy における バージョン 2.4 と 2.3 （2016 å¹´ 12 月公開）の差分と、 バージョン 2.4 と 2.2 （2013 å¹´ 7 月公開）の差分は、それぞれ GitHub で参照できます。 バージョン 2.4.1 はバージョン 2.4 の規範的な内容を変えずに構成を一新したものです。

今回の CA Communication は関係する各 CA の Primary Point of Contact (POC) へメールで送信され、14 の調査項目に対する返答を求めています。 調査項目の一覧は こちら から確認できます。 この調査に対する返答は Common CA Database を通じて 自動で速やかに公開 されます。

この調査に加え、 mozilla.dev.security.policy フォーラムにおける議論に従うことを追加要件として検討中であることを CA に通知しました。 このフォーラムでは、 Mozilla’s CA Certificate Policy で予定されている変更や、ポリシーと期待に関する質問や明確化、 ルート証明書の追加・変更申請、 CA/Browser Forum’s Baseline Requirements や他の要件に準じていない証明書に関する議論などが行われています。 フォーラムでの議論に参加することは CA に要求しませんが、 議論の内容を認識しておくことのみ要件とします。 しかしながら、将来の Mozilla’s CA Certificate Program をより良いものとするため、 各 CA が議論に参加していただけることを望んでいます。

この CA Communication は、CA が Mozilla’s CA Certificate Program に参加できるかどうかは私たちの判断 のみで決まること、また私たちのユーザを保護するためにはいかなる手段をも講じることを、 今一度繰り返し強調するものです。 とはいえ、セキュリティを維持する方法として最も良いのは、 パートナーとして CA と協力していくこと、 オープンで率直なコミュニケーションを促していくこと、 現状のさらなる改善方法を探すために努力していくことだと Mozilla は考えています。

Mozilla Security Team