Mozilla Security Blog 日本語版

Mozilla Security Blog を日本語に翻訳（非公式）

【翻訳】アドオンのピン留めに関する脆弱性とセキュリティ更新

この記事は、2016 年 9 月 16 日付で Mozilla Security Blog に投稿された Update on add-on pinning vulnerability（筆者: Selena Deckelmann）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

Firefox と Tor Browser が特殊な条件下で「中間者攻撃」（MITM）に脆弱であることが、今週（訳注：2016 年 9 月第 3 週）の初めにセキュリティ研究者によって報告されました。Firefox はインストール済みのアドオンを HTTPS 通信で自動的に更新しますが、証明書の誤発行に対する追加対策として、Firefox は Mozilla の web サイトの証明書も「ピン留め」しています。そのため、Mozilla の更新サイトを騙った未認証の証明書を攻撃者が取得できた場合でも、アドオンの更新過程を危殆化させることはできません。

Firefox のリリース時に "Preloaded Public Key Pinning" を更新する過程に隙があったため、2016 年 9 月 10 日以降の Firefox 48、そして 2016 年 9 月 3 日以降の Firefox ESR 45.3.0 において、アドオン更新時に参照すべきピン留めが無効になっていました。その時点において、Mozilla の web サイトとして誤発行された証明書を取得できた攻撃者であれば、自身の掌握するネットワーク上にいる任意のユーザに対して、アドオンの更新時に悪意のある内容を受信させることが可能でした。

アドオンを何もインストールしていないユーザに影響はありません。しかしながら、Tor Browser はアドオンを含んでいるため、Tor Browser の全ユーザは脆弱である可能性があります。悪意のある証明書の存在は現時点まで確認できておらず、そのような証明書を取得するには認証局をハッキングないし危殆化させる必要があります。しかし今回の事案は、国家レベルの攻撃から保護されたい Tor ユーザにとっては懸念事項と思います。Tor Project はセキュリティ更新を金曜（2016 年 9 月 16 日）の初めにリリースしており、Mozilla は Firefox の修正版を 9 月 20 日（火）にリリースします。

Firefox を最近更新していないユーザのため、アドオンの更新サーバに Public Key Pinning Extension for HTTP（HPKP）も適用しました。毎日行われるアドオンの更新確認の際に新しいピン留めが適用されるため、それ以降のユーザは攻撃から保護されることになります。

【翻訳】Firefox AddressSanitizer ビルドの配布場所が変更になりました

この記事は、2016 年 9 月 9 日付で Mozilla Security Blog に投稿された Firefox AddressSanitizer builds have been moved（筆者: decoder）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

今回のお知らせは、AddressSanitizer (ASan) を組み込んだプレビルド版の Firefox を使用しているセキュリティ研究者の皆さんに向けたものです。ASan ビルド版は Mozilla の FTP サーバから先日までダウンロードできましたが、内部ビルドインフラの変更により配布場所が変わります。今後は TaskCluster というビルドシステムからダウンロードできます。ほとんどの場合、テスト目的であれば最新版のビルドで十分です。最新版のダウンロードは以下のリンクから簡単に行えます。

Firefox AddressSanitizer ビルドの最新版

TaskCkuster の公開 API を利用すれば、より詳細なクエリをシステムに発行することができます（例：過去のビルドの取得）。詳しくは こちらのドキュメント を参照してください。

【翻訳】Firefox における MIME Confusion Attack の防止

この記事は、2016 年 8 月 26 日付で Mozilla Security Blog に投稿された Mitigating MIME Confusion Attacks in Firefox（筆者: Christoph Kerschbaumer）の翻訳です。この翻訳は公式なものではありません。詳しくはこちらをご覧ください。

web サーバが Content-Type を指定しなくとも、web ブラウザはファイルの内容をスキャンしてファイル形式を判別することができます。例えば、スクリプトを受信するリクエストを Firefox から web サーバに投げた結果、web サーバが "image/jpg" の Content-Type でスクリプトを返した場合でも、Firefox は本来のファイル形式を判別できるのでスクリプトが実行されます。この技術は俗に「MIME スニッフィング」と呼ばれており、コンテンツのメタデータが間違っていたり、もしくは完全に欠落していたりしても、コンテンツの解釈に必要な情報を補うことができます。Firefox は正しいファイル形式を判別する際、文脈となる情報（該当する通信のきっかけとなった HTML 要素）を利用したり、ファイルの先頭バイトに書かれたメディアタイプを確認していました。MIME スニッフィングは多くのユーザの web 体験を向上させている一方、MIME confusion attack という攻撃の原因にもなっています。

ユーザから画像をアップロードできる web アプリケーションを例に考えてみましょう。ただし、ユーザが正しい画像を実際にアップロードしたかどうかは確認していないものとします（ファイルの拡張子のみを検査している場合など）。このとき攻撃者は、スクリプトを含むように細工した画像をアップロードできてしまうため、確認作業は十分ではありません。。ブラウザは細工されたファイルを HTML として表示してしまうため、クロスサイトスクリプティング（XSS）攻撃の起きる可能性があります。しかし残念ながら、ファイルが polyglots（2 通りのファイル形式で解釈できるもの）であるかもしれません。例えば、GIF ファイルを細工することにより、画像としても JavaScript としても正しいファイルにすることができます。すなわち、ファイル形式の正しい解釈はコンテキストに依存することになります。

Firefox 50 以降からは、サーバがレスポンスヘッダで "X-Content-Type-Options: nosniff" を送信した場合（仕様）、読み込まれた時のコンテキストと MIME タイプが一致しないスタイルシート、画像、スクリプトを破棄するようになります。より正確に言うと、Content-Type がコンテキストに一致しないファイルが Firefox によってブロックされます（ファイル形式と許可される Content-Type の一覧は下を参照してください）。これにより、先程のような MIME confusion attacks を防ぐことになり、コンソールには次のようなメッセージが表示されます。

コンソールに表示されるエラーメッセージ

スタイルシートの正しい Content-Type

画像の正しい Content-Type

  • "image/" から始まるもの

スクリプトの正しい Content-Type