| ←世界樹の迷宮(3) | トップ | [重要] Sage++ (Higmmer's Edition)の高速HTMLフィルタの脆弱性対策について→ |
[重要] Sage++ (Higmmer's Edition)の脆弱性情報に関して、お詫びと釈明
- 今後の対応方針について
- 開発者の「個人情報」を守るために脆弱性を放置したことについて
- JPCERT/CCの発表以前に脆弱性の存在を公表したことについて
- Firefox/Sage及びSage++の危険性について
- 最後に
当ひまグで昨年10月5日頃より公開していたFirefoxの拡張機能Sageの私製改造版「Sage++ (Higmmer's Edition)」(現在公開自粛中。以下、Sage++と称す)に関連し、去る2007年1月18日に以下のエントリを公表致しました。
上記エントリについて、様々な方よりご批判、お叱りの声を頂いております。つきましては、ユーザーの方々、第一発見者及びJPCERT/CCの関係者の方々、並びに多くの皆様にご心配ご迷惑をおかけしていることに対して深くお詫び申し上げます。誠に申し訳ありません。
何を申し上げても見苦しい言い訳との謗りは免れないものと存じますが、この際、今後の対応方針及び上記エントリの公表に至った経緯、並びにSage/Sage++の危険性に関して説明させて頂きたく存じます。
1. 今後の対応方針について
今回の問題に関しまして、以下の通り対応させて頂きたく存じます。
- 脆弱性が修正されるまでの間、Sage++の公開を自粛致します。
- 本家Sageプロジェクトより修正版がリリースされ次第、それを反映したSage++を期間限定で配布致します。
- それを持ちまして、Sage++の開発・配布並びにメンテナンス作業を終了させて頂きます(*)。
2. 開発者の「個人情報」を守るために脆弱性を放置したことについて
JPCERT/CCの担当者様より「Sage++に脆弱性の報告がある」との第一報を頂いたのが昨年12月14日でした(左のサイドバー内に設置してあるメールフォームよりご連絡頂きました)。その後のやり取りの中で「脆弱性情報の詳細」を受け取るには「製品開発者リスト(開発者ベンダ登録リスト)」(以下リストと称す)への登録が必要なこと、その際このような様式にて開発者の住所・氏名・電話番号等を通知する必要があることを知りました。
また、上記ページによるとその後更に書面にて「JPCERT コーディネーションセンター製品開発者リスト登録規約」に同意して署名・捺印の上返送する必要があることを知りました。その規約の第3条には以下のように定められています。
3. 登録資格
「本リスト」に、名簿登録される者（以下、「本登録者」という。）は、以下の資格を満たす必要がある。
- ｢本取扱基準」における「製品開発者」に該当すること
- 経済産業省告示第二百三十五号を遵守すること
- ｢本規約｣を遵守すること
- 別途定めるJPCERT/CC脆弱性関連情報取り扱いガイドラインに準拠すること
率直に申し上げて「経済産業省告示云々……」という文言を見ただけで一介の個人ブロガーに過ぎない私としましては腰が引けてしまいました。また、関連する以下の資料にもさっと目を通しましたが、
いずれも私にとって敷居が高いと思える内容であり(JPCERT/CCの活動を批判したいわけではありません)、正直申し上げてあまり関わりたくないと思いました。然るに登録方法のページを見ると(リストへの)登録申請においては「会社の登記簿謄本」が必要と明記してあるように、この枠組みは基本的には開発者が「企業又は団体」である場合を主に想定しているような気がしました(私個人の勝手な解釈です、念のため)。
また、前回のエントリでも述べさせて頂きました通り、リストへの登録に際して個人情報の登録が必要なことも私にとっては大きな障壁となりました。JVN(脆弱性公表サイト)での公表にあたってはベンダ名以外の登録情報が公開されることはないことは理解しておりますが、昨今の情報漏洩事案の多さに鑑み、個人情報を守るには情報をなるべく外に出さないことが第一原則であると考え、今回は登録を辞退させて頂くこととしました。尚、この決断にあたっては結城浩先生のこのご意見も参考にさせて頂きました(*)。この事例もオリジナルのソフトウェアを元にした改造版であり、私の場合と類似していると思います(**)。
(*) お名前を出してすみません＞結城先生
(**) 結城先生の場合は「JVNによる公表後、(その概要情報を元に)脆弱性の対策を行った」事例であり、「脆弱性の存在を知りつつ放置」し、且つ「対策前にその存在を公表した」私の場合とは似て非なる状況です。あくまでもこれは脆弱性情報入手のためにJPCERT/CCに開発者登録をするかどうかの判断の事例として紹介したものであることを付言させて頂きます(1/26追記)。
いずれにしましても、私自身が開発者としての責任から逃れたことは事実であり、弁解のしようがないことは重々承知しております。ここに改めてお詫び申し上げます。
3. JPCERT/CCの発表以前に脆弱性の存在を公表したことについて
ご批判を頂いているもうひとつの点として、脆弱性の修復及びJPCERT/CCによる発表以前に当該脆弱性の存在を公表したことの是非を問う声を頂いております。以下この点に関してご説明申し上げます。
公表に踏み切ったきっかけはJPCERT/CCより「フレッシュリーダーにおける RSS フィード クロスサイトスクリプティングの脆弱性」が発表されたことです。RSSリーダーの問題という類似性、及び発表時期から考えて、Sage++への脆弱性報告と同じ又は近い時期に通報された事案である可能性が高いのではないかと感じました。また、私への通報日から考えて、Sage++の脆弱性情報が公開されるのも時間の問題ではないかとも思いました。JPCERT/CCのガイドラインによりますと第4-1項に「一般公表日の決定の際には、JPCERT/CCが脆弱性関連情報の取り扱いを開始した日時から起算して45日後を目安とします」と定められています。私に第一報が届いたのが昨年12月14日でしたから、そこから起算すると一般公表日は1月28日前後になろうかと思います(第一発見者による通報はそれ以前でしょうから、もっと早まる可能性もあります)。
また、私が過去に本家Sageプロジェクトに対してある脆弱性の連絡をした際、修復までに43日を要したことから類推しても、今回の脆弱性情報が公開される日は近いと考えました。
私としましては、過去Sageに存在した幾つかの脆弱性に対して(情報提供者の方のご協力も得て)本家よりも早く対策した(*)という自負もあり、また当該脆弱性情報が公開されてから修復作業に数日を要する可能性もあることから、できれば一般公表の前に脆弱性を修正したいと考えました。JPCERT/CCによる調整を拒んだ以上、第一発見者の方と直接コンタクトを取るしか方法はありません。つまり前回エントリの「〜業務連絡〜」以降が私の真にお伝えしたい内容だったのです。しかし、それだけでは他の読者の方にとっては意味不明な内容となってしまいますので、簡単な事情を説明する文章を掲載しました。
脆弱性の存在を公表することで悪意ある第三者に情報を与え、一般ユーザーへの攻撃のリスクを増大させるとのご批判は確かにその通りです。しかし、一般にRSS/Atomフィード並びにRSSリーダーに脆弱性が存在し得ることについては広く知られた事実です。しかもSage及びSage++はいわゆる「オープンソース」ソフトであり、多少の知識がある方なら脆弱性を探すことはごく簡単に行えます(現に、私自身が数件の脆弱性を発見、修復しました)。また、Sage++に未知の脆弱性が存在する可能性があることについては当初より配布ページの「使用上のご注意」に明記してあります。
それならば、一刻も早く第一発見者の方とコンタクトを取って詳細情報を入手し、速やかに修正版をリリースしたいと考えました(思い返すに脆弱性情報をIPAを通じて届出るほど慎重な方が、身元不明な個人ブロガーに情報提供して頂けるはずがないと知るべきでした)。その間、一般ユーザーの方々には注意を促せば大丈夫だろうと誤った判断をしてしまいました。過去にも他の方のブログ等でSageの脆弱性が指摘されたことがあり、「脆弱性の存在」を公表するだけならば大きな問題にはならないだろうと甘く考えていたことに対し、深く反省しております。
また、このフライング行為によってJPCERT/CCという組織の活動そのものに悪影響を及ぼしかねない事態を招きましたことに対して、関係者の方々に謝罪致します。
4. Firefox/Sage及びSage++の危険性について
最速インターフェース研究会さんで、このような指摘がありました。
そもそもの問題として「ローカルディスク上のHTMLファイルをブラウザで開くと超危険」です。XMLHttpRequestやIFRAMEでローカルファイルの内容を読み取れるからです。Sageに脆弱性があるということは、あらゆる個人情報の漏洩につながります。
(中略)
Sageは危険です。はっきり危険だと言うべきです。「未修正の脆弱性があるから」というのはもちろんですが、脆弱性があった場合の影響範囲がでかいので危険だと考えるべきです。Sageのユーザーに悪意のあるフィードを購読させる、という手間がかかるので、起こりうる確率としては低いでしょうが、攻撃に成功すれば攻撃者はローカルディスクの全内容を取得できます。
最速インターフェース研究会 :: フィードリーダーの脆弱性まわりのこと
上記のご意見は基本的には正しいです。但し、Sageが危険なのは「ローカルディスク上のHTMLファイルをブラウザで開く」からだけではないと私は考えます。強いていうなら「Firefoxの拡張機能という仕組みそのものが危険(*)」というべきです。
確かに、過去Sage 1.3.xで発覚したスクリプトインジェクション系の脆弱性は「ローカルHTMLファイルに任意のスクリプトが混入する危険性がある」というものでした。しかし、上記ページでも言及されているように、フィードをローカルHTMLファイルに展開しないはずのSage 1.4でも同様の脆弱性があることが私の調査によって判明しています。
周知のようにSage 1.4では拡張機能が使用するchromeスキーム内で動的にページを生成しており、ローカルディスクからHTMLファイルを読み込んでいるわけではありません。しかしchrome自体がいわば特権モードであり、何らかの方法を用いてスクリプトを動作させることできれば、ファイルの読み/書きや外部との通信、DLLの起動などあらゆる攻撃が実現する可能性があります(あくまで可能性の話で実際に可能かどうかは不明です)。また、chromeスキームで動作するが故に、私が試した限りではNoScript拡張でもスクリプトの実行を防ぐことはできませんでした(対処法をご存知の方はご連絡頂けると助かります)。
つまるところ、Firefoxにおいては拡張機能をインストールすること自体が「リスクを伴う」行為であり、ましてや私のようなどこの誰ともつかぬ人間が手を加えたいわゆる「野良拡張」に手を出すことは常に「重大な危険性」と隣り合わせであることを認識する必要があります。開き直りのように聞こえるかも知れませんが、このことは往年のFirefoxユーザーにとっては半ば常識のようなものと考えておりましたので、ご批判は覚悟の上で敢えて表明しておきたいと思います。
尚、Sage 1.4に存在する上記脆弱性は、現時点(1/25)においてSageの開発ページからダウンロードできる"sage_nightly.xpi"においても修復されていないことを確認済みです。というより私の見るところ1.4系列のコードは昨年10月5日頃を最後にメンテナンスが行われていない模様です(*)。その理由は不明ですが、事実上の開発中断状態であると見られます。
(**) CVSディレクトリ内のファイルが一部更新されているのを確認。開発再開か? (2/3追記)
以上のことから、Firefoxの拡張機能「Sage 1.3.x」「Sage 1.4」及び「Sage++ (Higmmer's Edition)」はまさに「非常に危険な」拡張機能のひとつであり、現時点では一般ユーザーが気軽に使用することを推奨できるソフトウェアではないと言わざるを得ません。ご使用にあたってはそのメリット・デメリットをよく考慮の上、各自の「自己責任」(本来この言葉はあまり好きではないのですが)の元において使用を継続するなり、中止するなりのご判断をして頂きたいと思います。
ちなみに「HTMLタグを許可する」又は「フィードをコンテンツエリアに読み込む」をオフにした場合はフィード内のHTMLタグが解釈されることはない(はず)ですので多少のリスク回避にはなりますが、今回指摘を受けた脆弱性の詳細(*)が不明な以上、必ずしも安全であると断言することはできません。
尚、参考情報として、当ひまグで公開していた「Sage++ (Higmmer's Edition) 1.3.9」については、以下のサイトで公開されているテストフィードを全てPassすることは確認済みであることを申し添えておきます(HTMLフィルタ方式＝高速/詳細の両条件において)。
- snellspace.comで公開されている以下のフィード
- http://www.snellspace.com/public/everything.atom (他、全5種類) - RSS Reader Security Checkで公開されている以下のフィード
- http://www.izynews.com/en/safe_rss/check.xml
当然ながら、これらのテスト結果はSage++の安全性について何ら保証するものではありません。もし、これら以外にもテスト用フィードをご存知の方がいらっしゃいましたら教えて頂けると助かります。追ってこちらでテストの上結果を公表したいと思います。
葉っぱ日記さんに教えて頂いたフィード(OPMLファイル)を使ってテストした結果、早速新たな脆弱性が判明しました(情報提供に感謝します)。
- - http://security.grazr.com/FeedTestSuite.opml によるテスト結果
- HTMLフィルタ方式:高速
→ Fail: Non-Alpha-Non-Digit, Double_open_angle_brackets, Evade_Regex_Filter2 - HTMLフィルタ方式:詳細
→ 全てPass
- HTMLフィルタ方式:高速
- [対策] HTMLフィルタ方式を「詳細」で使用するか、「HTMLタグを許可する」又は「フィードをコンテンツエリアに読み込む」をオフにして下さい。
HTMLフィルタの設定方法については以下のページを参照して下さい。
尚、これらのテスト結果を公表することに関しては異論もあろうかと思いますが、私としては既に公知になっているテストファイルによる検証結果を隠蔽するよりも公表して対策方法を周知徹底することの方がユーザーの方々の利益に適うと考え、ここに公表させて頂いております。(以上、1/26追記)
(1/27追記) 高速フィルタでFailの項に「Non-Alpha-Non-Digit」が抜けていたのを追記しました。
(1/28追記) 現在判明している脆弱性情報をこちらのエントリにまとめました。
(1/30追記) 上記Fail項目の内、「Non-Alpha-Non-Digit」「Evade_Regex_Filter2」については公式版Sage 1.3.10で修正されたことを確認しました。しかし、残る「Double_open_angle_brackets」については未だに修正されていない模様です。詳しくはこちらのエントリを参照して下さい。尚、拙作のSage++ 1.3.10では高速HTMLフィルタが使用不能になっており、上記脆弱性は発生しません。
(2/10追記) JVNより当該脆弱性に関する情報が公開されたのを受けて補足エントリを掲載しました。
5. 最後に
以上、つらつらと言い訳がましく長文を書いてしまいましたが、これが現時点での私自身の嘘偽らざる心境です。最後に、今回ご心配ご迷惑をおかけ致しました全ての皆様に対しまして、ここに改めてお詫びを申し上げたいと存じます。誠に申し訳ありませんでした。
ひぐまのひまグ管理人
ひぐま
| ←世界樹の迷宮(3) | トップ | [重要] Sage++ (Higmmer's Edition)の高速HTMLフィルタの脆弱性対策について→ |
トラックバック
この記事について書く(FC2ブログユーザー)
※言及リンクの無いトラックバックは無効です
コメント
もし気になるのなら、「未知の脆弱性が存在する可能性があるというリスクを承知の上、ご使用ください」といった感じの文を添えておけばいいんじゃないでしょうか。
おかしな因縁をつけてきて謎のメンバー登録を迫る怪しげな団体に従う必要はありません。
政府公認の組織でも犯罪を犯す時代ですからね。
「Firefoxの拡張機能という仕組みそのものが危険」という表現は誤解を生むものと思います。
まず Firefox ユーザが知らなければならないのは、特権モードとかそういうことではなく、「拡張を導入するということは Firefox 自体の改造に他ならない」ということです。インストールした拡張は Firefox の一部になるということです。これは拡張を作っている人なら誰でも知っている常識ですよね。
また拡張は XPCOM などにも自由にアクセスできて、なんでもできてしまいます。Windows 版であれば条件はありますが悪意のある拡張を配布して、C ドライブの全ファイルを削除することなんて朝飯前です。
そんなこともあり、piro さんだったか、のりさんだったかわすれましたが、サイト上で、安易な拡張のインストールの危険性について意見を交換したことがあります。
そのときの結論は「拡張のインストールは IE の署名つき ActiveX をインストールするよりはるかにリスクがある」でした。
もちろん Add-ons で公開されている拡張も例外ではありません。なにせ署名すらされてない拡張を平気で公開しているのですから。また署名が当該拡張の安全性を担保するものでもないことも確かですし。
ただ「安全な拡張も、脆弱性のある拡張も Add-ons で混在して公開されている」という事実はユーザに伝える必要はあると思います。私は Mozilla Foundation も Mozilla Japan もそれを怠っていると考えています。
やはり一番の問題は、Mozilla Foundation が「拡張の作成、配布」を管理できない現状が問題なのだと考えています。
ちなみに Add-ons で公開されている拡張は、拡張作者有志によりチェックは行われています。Add-ons で拡張の公開要請から実際に公開されるまでに時間がかかるのはそのためです。
しかしこの拡張を公開するシステムが、拡張の安全性を担保しているとは決して言えません。
今回 Sage に脆弱性が発見されたという事実は変わりませんし、上記のような問題もあります。
でもだからといって、すべての拡張が危険と誤解される表現は適切な表現でしょうか？
確実に言えるのは、すべての拡張が危険だと言うわけではない、ということです。
問題は拡張を管理する手段が Mozilla Foundation に存在しない、ということです（こちらの方がもっと深刻な問題です）。
そのことは間違わないでください。
もし「XMLHttpRequestやIFRAMEでローカルファイルの内容を読み取れる」のなら、それは拡張の問題ではなくて、明らかに Firefox 自体の脆弱性ですね。XPCOM に実装されている関数によるローカルファイルアクセスは機能ですけど(これがないと Firefox の設定ファイル自体の I/O ができない)。
どう考えても critical な脆弱性ですから、Mozilla Foundation に一報入れておいた方がいいのではないでしょうか。
「拡張機能が」ではなく「仕組みが」としたのは
まさにおっしゃられたようなこと(インストールのリスク)を申し上げたかったのですが、
ご指摘を受けて注釈を追記させて頂きました。
>「ローカルファイルの内容を読み取れる」
具体的方法は差し控えさせて頂きますが、とりあえずできたのは事実です。
ただ、私自身はそれ自体は(Fx本体の)脆弱性とは認識していませんでした。
むしろ「できて当然」という感覚でしかありませんでした。
(最速さんがおっしゃる"saved from url"という仕組みも知りませんでしたし…)
どこまでがFirefoxの仕様で何が脆弱性かの理解も未だ十分ではないのですが、
とりあえず報告はするようにします。
貴重なご意見どうもありがとうございました。
(コメント修正:14:20)
最速インターフェース研究会さんのブログエントリにを読む限りでは、古くさいブラウザ比較安全論を書いているだけのようですし。しかも Web 非標準を評価してますし。
IE、Mozilla Firefox、Opera 等のどれが安全かなんてことを書くのは全く意味がないっす。
結論から言えば、どれも安全ではないですから。
どこの会社も脆弱性が発覚すれば修正します。ユーザはただその修正を待てばいいだけです。というか待つことしかできないでしょ。
私は IE の XMLHttpRequest オブジェクトの脆弱性の実験をして、それが実在することを知っていますから（どんな脆弱性があるかは私のページの Ajax のページを見てもらえればわかります）。だから IE と Firefox など他のブラウザを比較するようなエントリ（どちらを贔屓しているにしても）を見ると、そのエントリに価値を見いだすことができません。
そんなことを知ってブログのネタにする暇があるくらいなら、Firefox 場合なら Mozilla Foundation に、Opera なら Opera Software に早急に連絡するべきでしょう。それが脆弱性を知った人間の責任ある行動ではないでしょうか?
このセリフ、Microsoft も言ってますよ。
Bug 16320 - content filter exploit
http://mozdev.org/bugs/show_bug.cgi?id=16320
また、現時点（30日12:30)では本家では何もアナウンスされていませんが、1.3.10 がリリースされた模様です。（アドオンの更新チェックでリストアップされて来ます）
また私のマシンの Firefox の Sage もバージョンアップされました。
これで、とりあえずこの話題は今回は打ち止めですね （＾＿＾）
でも私の実験ではリモートにある HTML ファイルから XMLHttpRequestやIFRAMEでローカルファイルの内容は読み取れなかったんですけどねぇ。
おかしいなぁ。テストの方法が悪いのかな？
だからできて当然(?)と思っていたんですけど……。
> だからできて当然(?)と思っていたんですけど……。
結論から書きますね。ひぐまさんの検証の方法ではできて当然です。
というのは Firefox の仕様ではセキュリティのため XMLHttpRequest や IFRAME は、元の HTML ファイルのある URI からのものだけしか、GET できないように実装しているからです。
ローカルファイルの URI は file:/// で始まるファイルのフルパスになります。ですから当然 file:/// で始まるオブジェクトを XMLHttpRequest や IFRAME が読み込めるのは当たり前です。
これは脆弱性でもなんでもありません。
それより問題は HTML メールです。HTML メールはローカルに存在します。だから攻撃のシナリオとしては Firefox を狙うより Thanderbird が狙われた方が危険です。
Thanderbird では最低でも JavaScript は必ず常に切っておくべきでしょう。
ちなみに私は HTML メールに対応していない電信八号を愛用しています。バッファーオーバーフローの脆弱性でもない限り、安全だからです。
詳細な情報を提供するため、こちらから個人情報を登録してください」
ってか。
コメントの投稿
| ←世界樹の迷宮(3) | トップ | [重要] Sage++ (Higmmer's Edition)の高速HTMLフィルタの脆弱性対策について→ |
