Home > Latest topics

Latest topics > Firefox 3で安全にアドオンを配布するための方法のまとめ

宣伝1。日経LinuxにてLinuxの基礎?を紹介する漫画「シス管系女子」を連載させていただいています。 以下の特設サイトにて、単行本まんがでわかるLinux シス管系女子の試し読みが可能! シス管系女子って何!? - 「シス管系女子」特設サイト

宣伝2。Firefox Hacks Rebooted発売中。本書の1/3を使って、再起動不要なアドオンの作り方のテクニックや非同期処理の効率のいい書き方などを解説しています。既刊のFirefox 3 Hacks拡張機能開発チュートリアルと併せてどうぞ。

Firefox Hacks Rebooted ―Mozillaテクノロジ徹底活用テクニック
浅井 智也 池田 譲治 小山田 昌史 五味渕 大賀 下田 洋志 寺田 真 松澤 太郎
オライリージャパン

Firefox 3で安全にアドオンを配布するための方法のまとめ - Dec 25, 2007

第8回Mozilla拡張機能勉強会プレゼン資料を公開した

以下、内容を改めて整理してみる。

update.rdfの確実性の保証

まず、Firefox 3ではセキュアな方法で自動更新が行われないアドオンはインストールできなくなる。ここでいう「セキュアな自動更新」とは、「インストールされたアドオンについて、自動更新でダウンロードしてきた新バージョンのXPIパッケージが、そのアドオンの作者が提供した物であると確実に保証できる」ということを指している。

その挙動を実現するために、Firefox 3ではアドオンのマニフェストファイルの解析時に、以下の判別が行われる。

  1. そのアドオンの自動更新のための情報(以下、update.rdf)がSSLを使って提供されているか?(update.rdfのURIのスキーマ部分が「https」であるか?) また、その場合、それはオレオレ証明書ではなく、ベリサインなどのきちんとした認証機関によって証明された物であるか?
  2. SSLを使ったものでない場合、取得したupdate.rdfの署名を検証するための公開鍵は含まれているか?

Firefoxのアドオンのupdate.rdfはXML形式のリソースとして提供される。そのupdate.rdfの中に、新しいバージョンのアドオンのXPIインストーラのダウンロードURIが記述されている。ということは、このupdate.rdfが通信経路上で改竄される可能性がある――他人が別のリソースを「これがupdate.rdfですよ」と偽って、アドオン作者になりすまして送信できる――場合、最悪のケースでは、「本来の作者が作ったものではない、悪意あるコードが含まれた偽物のインストーラ」を掴まされてしまう恐れがある。よって、上記のどちらかの条件に適合しない場合、そのアドオンのインストールはFirefox 3によって拒否されるようになる。

1の場合はSSLで通信するからまぁ安全、ということでとりあえず説明は省略する(SSLだけじゃ安全じゃねえよとツッコみたい人はいるかもしれないけど)。

2の場合、update.rdfはXML署名という技術によって署名が施されることになる。簡単に言うと、update.rdfの内容そのものと、アドオン作者のみが持つ秘密鍵(という名前の数字)を元にして、暗号化された文字列が生成され、それがupdate.rdfに埋め込まれる。この「埋め込まれた文字列」が「署名」となる。この「署名」は、アドオンのinstall.rdfに書き込まれた公開鍵(という名前の数字)を使えば暗号化される前の状態に戻すことができるので、それをupdate.rdfの内容と比較して一致すれば、そのupdate.rdfは確かに元のアドオン作者が作ったままの内容から少しも改竄されていないし、そのupdate.rdfは確かに元のアドオン作者でなければ作ることができない、ということが保証できる。

ダウンロードした新バージョンのXPIの確実性の保証

さて、こうして取得した「確かにアドオン作者自身が提供した通りの内容である」ことが保証されたupdate.rdfであるが、このリソースには新バージョンのアドオンのXPIファイルをダウンロードするためのURIの情報しか含まれていない。そこでさらにそのファイルをダウンロードする作業があるわけだけれども、ここでまたもう一度チェックが入る。

  1. そのXPIインストーラはSSLを使って提供されているか?(ダウンロード用URIのスキーマ部分が「https」であるか?) また、その場合、それはオレオレ証明書ではなく、ベリサインなどのきちんとした認証機関によって証明された物であるか?
  2. SSLを使ったものでない場合、ダウンロードしたXPIインストーラを検証するためのハッシュがupdate.rdfに含まれているか?

1の場合は前項同様省略する。

2の場合、アドオン作者はまず、新バージョンのXPIインストーラのファイルの内容を要約した一意な文字列を生成する。これを「ハッシュ」と言って、SHA1やSHA512などアルゴリズムは何種類かあるんだけれども、統計的手法によって「似た内容のファイルからは同じハッシュは生成されない」ように考えられている。update.rdfにはそのハッシュが書き込まれていて、実際にダウンロードされたファイルの内容を元にFirefoxがハッシュを計算して、「実際のファイルのハッシュ」とupdate.rdfに書き込まれていた「ダウンロードされるべきファイルのハッシュ」とが等しければ、ダウンロードしたファイルは確かに元のアドオン作者が作成した物であるということが保証できる。

McCoyの仕事

McCoyは、ここまでの話で出てきたうちの、「update.rdfに署名を施す」「その署名を検証するための公開鍵をinstall.rdfに埋め込む」の部分を担当するソフトウェアだ。(なお、秘密鍵と公開鍵のペアは自動的に生成されるので、アドオン作者自身が秘密鍵の存在を意識することはない。)使い方はリンク先の文書か、くでんさんによる解説を読んで欲しい。

McCoyではできないこと

McCoyを使うことで「自動更新をセキュアにする」ことはできる。でも、その前のステップである「そのアドオンを初めてのインストールをセキュアにする」ことはできない。初めてインストールする時の時点で偽物のインストーラを掴まされた場合、この仕組みは破綻してしまう。

初めてのインストールをセキュアにするためには、そのアドオン自体に署名を付けるか、SSLを使って配布するか、ハッシュを比較するしかない。しかし……

  • XPIインストーラに署名を付けるには、会社の登記簿謄本が必要で、お金もかかる。実質、企業限定の方法である。
  • SSLを使うには、SSLを使えるサーバを調達するコスト、認証局証明書を購入するコストがかかる。
  • ハッシュを比較させるには、そもそも、比較用の「正しいハッシュ」を何らかのセキュアな方法で提供しなければいけない。結局の所、SSLを使わずに、アドオン作者がユーザに対してセキュアにハッシュを渡す方法は、実質的には無いと言っていい。

などの問題がある。

SSLが使えるのであれば、McCoyを使ってupdate.rdfに署名を施す必要性は薄い。自前でSSLが使えるサーバを用意できるなら問題ないし、そうでなくても、Mozilla Add-onsでは標準でSSLを使用しているので、ここにアドオンを登録しさえすれば初回インストールも自動更新も全部がセキュアになる。よって、McCoyが本当に必要になる場面は、以下のどちらかの場合ということになる。

  • 最初のインストールに関しては、データの手渡しやイントラネットの配布、署名されたメールでの配信など、何らかの方法で確実性を保証することができる。
  • Mozilla Add-onsに登録することができないアドオンである(社内用に秘密裏に開発・配布しないといけない、など)。

ちなみに、僕は自動更新はMcCoyを使ってセキュアにしているけれども、初回インストールについては、セキュアでないことを承知の上で普通にhttpで署名無しのXPIインストーラを配布している。この点については責められてもしょうがないので何も言えない。

Mozilla Add-onsの問題

個人のアドオン作者としては、配布場所をMozilla Add-onsに一本化できるならそれが一番セキュアだし簡単便利だし(今はMozilla Add-onsのUIは日本語化されていて、英語ができなくてもアドオンを簡単に登録できる上、ここに登録すればupdate.rdfもMozilla Add-ons側で提供してくれる)で万々歳なんだけれども、唯一のネックがあって、それは、「一般ユーザから見える場所に置かれるには時間がかかる」ということ。

新しく作成したアドオンは「レビューがついて」「作者が公開申請をして」「そのレビューの内容が妥当と認められて」「エディタが公開を認める」まてずっと一般ユーザの目からは隠されたままになる。また、公開されたアドオンの新しいバージョンをアップロードしても、「エディタがそのアップデート版を検証して、問題ないと確認されて」初めて一般ユーザ向けに公開される。このタイムラグが、Mozilla Add-onsを全面的にお勧めしづらい最大の理由だ。先日もXUL/Migemoのアップデート版が公開を承認されるまで1ヶ月以上かかってしまっていたし、現実的に、このレビューの仕組みはすでに破綻していると言っていいと思う。

せめて、「レビューされていようがいまいが、エディタの審査をパスしていようがいまいが、一般ユーザから自由に見ることはできる」「ただし、レビューされていなかったり、エディタの審査をパスしていなかったりする物については、それ相応の警告を出す」という風な運用に変えてもらえれば、それで十分Mozilla Add-onsに一本化できるんだけど……

分類:Mozilla > XUL, , , , , , , 時刻:03:23 | Comments/Trackbacks (4) | Edit

Comments/Trackbacks

no title

Firefox 3以降で「そのアドオンを初めてのインストール」でもアドオンパッケージ内のinstall.rdfにupdateURLが記載されていてそのリンク先のupdate.rdfがMcCoyで署名されていれば、署名検証できなかったらインストールできないから、アドオンパッケージとupdate.rdfの両方が偽物な場合以外はアドオン開発者が提供しようとしたパッケージであると確認できると思います。
McCoyによる署名はもともと中間者攻撃対策ですから、配布ページそのものの真偽や配布ページが他者に乗っ取られてないかは保証できませんね。それを云うとHTTPで公開されているWebというシステムそのものを疑ってかかることになるような気がしますけど……
HTTPSでAMOのスタッフとアドオン開発者しか編集できないAMOのユーザプロフィールのページに、McCoyの公開鍵(updateKey)を書けたらいいんでしょうけど、あんまりユーザプロフィールにいろいろ書けるようにすると、自分や自社の宣伝その他余計なことをいっぱい書く人や団体が出てくる可能性があるからちょっと考えないといけないでしょうね。
ユーザ的には気休めですが、AMOのユーザプロフィールのページのAMOのアドオン開発者のWebページへのリンクのリンク先からしかアドオンをダウンロードしないとか。
以前にここのコメント欄にも私が書いた記憶がありますしMozilla Updateができた時点から思ってましたけど、能力的意欲的にエディタがすることができる人が限られる以上(それほど増加が見込めない)、アドオン作成が活発になってAMOに申請される数が増えると、どう考えてもエディタによるチェックというシステムは破綻します。とりあえず、そこらへん考えてのサンドボックスですから。チェックしていないよりはマシな程度でも「一般ユーザ」の目に触れるアドオンは一応チェックしていますよ、というのがウリなわけで「レビューされていようがいまいが、エディタの審査をパスしていようがいまいが、一般ユーザから自由に見ることはできる」「ただし、レビューされていなかったり、エディタの審査をパスしていなかったりする物については、それ相応の警告を出す」というのはちょっと難しいでしょうね。

Commented by くでん at 2007/12/25 (Tue) 06:58:41

[mozilla][extension][study]第八回Mozilla拡張機能勉強会

12月22日の第八回Mozilla拡張機能勉強会 Wikiに参加してきた。以下覚え書き。 mozilla Japanのエントランスに飾られていた、緑のgoo版Firefox?のクリスマスツリー。 電車の中で無線LANカードと名刺を忘れたことに気がつく。 参加予定者数が22名程と多いので、有線が確保で

Trackback from 「 Firefox ×?=!」を考えてみる、ブログ。 at 2007/12/26 (Wed) 00:01:32

Re: no title

> アドオンパッケージとupdate.rdfの両方が偽物な場合以外はアドオン開発者が提供しようとしたパッケージであると確認できると思います。

その「両方が偽者な場合」がありうるから問題なわけで。ご存知でしょうが、McCoy等によって実現される機能は

> それを云うとHTTPで公開されているWebというシステムそのものを疑ってかかることになるような気がしますけど……

のようにWebが疑わしい状態でも機能する(間違いなくアドオン作者が提供する更新のみを受け付ける)ように作られています。んで、インストール時の問題は、「ある利用者がダウンロードしたアドオンの作者が、その利用者が想定する作者(例えばPiroさん)と同じであるか確認できない」という問題です。例えばXさんがPiroさんの拡張機能の公開鍵とupdateURLだけを書き換え、それを中間者攻撃によってAさんにダウンロードさせたとすると、Aさんがダウンロードした拡張機能の作者はあくまでXさんであり、Xさんはその後の任意の時点で更新と称して悪意のあるコードを注入することが可能になってしまいます。

これを防ぐためには、くでんさんも書かれている通り公開鍵が想定するアドオン作者のものであることを確認する別の手段を用意することです。本気になればAMOと連携してアドオンインストール時にFirefoxが「この公開鍵はAMOアカウントの誰それのものと一致する」旨のメッセージを表示するように変更することは容易だと思いますが、今回のMcCoy関連では件の脆弱性修正のみが目的のようで、Mozillaの人たちが「大多数の人はAMOさえあれば十分なんでしょ?」というスタンスなら、それさえも難しいでしょうね。

ということで、Piroさんには率先して公開鍵をAMOで公開してほしいです。アカウントの「WebサイトURL」の項目に#として追加する、というのを考えたのですがいかがでしょう。あ、文字数の制限で元のURLが短い場合でないと入りきらないようですね……

Commented by takeshi at 2007/12/31 (Mon) 06:19:16

Mozillaの人は何を解決しようとしたのか

脆弱性のことをちょっと触れておくと、アドオンインストール時にはユーザの主体的な操作が求められるので問題ないが、その後は強制更新されるので更新の過程で別人の悪意のあるコードが紛れ込むのは問題がある。そもそも自動更新での更新内容は大抵の人は注意を払わないものであり、Firefox自体の更新のように自動更新はセキュアであるべきだという共通認識があるので、その部分が脆弱性と認識されて一連のMcCoyにつながるシステムが作られました。実際、インストール時に一度注意するのと、利用中ずっと注意し続けるのでは心構えに雲泥の差があると思います。

ただ、その解決方法はFirefox 2までと整合性を持たせるため現状との妥協点というか、必要最小限の変更でこの問題に対処しようとしたためにこんなになっちゃった、というやる気のなさが感じられます。

あと細かいところをいくつか。
サーバに対する証明書は認証局証明書とは言いません。サーバ証明書と呼んでおくのが無難です。Firefoxでは「サイト証明書」と呼んでますね。認証局証明書は「認証局を識別するための証明書」のことです。あと、以前も書きましたがMcCoy等によって生成される署名は独自形式のものなので、いわゆる「XML署名(XML Signature)」とは別ものだと思います。ついでにプレゼン資料を見てのコメントを。「ハッシュ」は「難読化」のカテゴリには入らないと思います。

Commented by takeshi at 2008/01/02 (Wed) 08:40:16

TrackBack ping me at


の末尾に2014年1月19日時点の日本の首相のファミリーネーム(ローマ字で回答)を繋げて下さい。例えば「noda」なら、「2007-12-25_secureaddon.trackbacknoda」です。これは機械的なトラックバックスパムを防止するための措置です。

Post a comment

writeback message: Ready to post a comment.

2014年1月19日時点の日本の首相のファミリーネーム(ひらがなで回答)

Powered by blosxom 2.0 + starter kit
Home

カテゴリ一覧

過去の記事

1999.2~2005.8

最近のつぶやき

オススメ

Mozilla Firefox ブラウザ無料ダウンロード