アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
Stableって古いって意味だっけ？ -- Debian初級
仕組みからして難しい気もする (スコア:2, 興味深い)
仕組み的にマシンの乗っ取りは難しいんじゃないかと思ってましたが、そういうことでしたか。
Re:仕組みからして難しい気もする (スコア:5, 参考になる)
・chrome( = 窓枠 = Firefoxそのもの)か content（ = 窓の中身 = 外部由来のHTMLなど）か
・2つのcontentのデータが同一サイト（と見なせる）かどうか
の2種類あって、前者を破られると「乗っ取り」、後者を破られると「クロスサイトスクリプティング(XSS)」が発生します。テーマ、拡張は基本的に「窓枠」の方の機能を増設するものなので、なんでもあり、なのです。
これとは別に、いわゆるプラグインはFirefoxの実行バイナリと同じファイル権限を持っています。もはやスクリプトでも何でもないので上記の2つと比較は出来ません。
仮にFirefoxが完全無欠だったとしても、これらのアドオン3種は権限が強いので、故意あるいは事故によって、セキュリティに穴を空けてしまう危険があります。うっかり脆弱なテーマを作ってしまうことはないと思いますが、故意に危険なコードを挿入されたテーマ、というのはあり得ます。逆に、サイドバーと検索プラグインはアドオンとは言え、同じ仮定の下ではどうあがいても安全です。
話を元に戻すと、Firefox単体で外部スクリプトにchrome権限を取られた事がないのか、というとあります。一番最近のやつは2006-43 Privilege escalation using addSelectionListener [mozilla.org]ですね。この"Privilege escalation"というのは、まさに外部スクリプトにchrome特権を与えてしまったという意味です。
例えば、window.open("http://www.example.com");というようなありふれたスクリプトを考えてみると、実は内部的に、nsIDOMWindowInternal::open(..)というXPCOMメソッドが呼ばれています。つまり、引数である"http://www.example.com"という外部スクリプトデータは、XPCOMレベルまで到達できるからこそ、新しい窓を開くという大胆な振る舞いが可能なのです。そして、元のwindow.openというコードが安全なのは、window.openからnsIDOMWindowInternal.openに至る経路上における権限の使い方が正常だからなのです。MFSA 2006-43のケースは、addSelectionListenerの引数を巧妙にすれば、外部スクリプトをchrome権限実行環境まで忍び込ませることが可能だった、というわけですね。
#今、この騒ぎのとばっちりで、公開済みのセキュリティバグもも閲覧できないようになっています。
但し、今回の件はこれらの背景とは全く関係のないスタックオーバーフローによるクラッシュです。CNETによると、彼らは「ソースが汚い」と文句を言っていたそうですが、私の推測では、単に彼らがどこでクラッシュしているのかカンファレンスまでに発見出来なかったので、ソースの所為ににしたと言うのが真相だと思います。なまじ分からないものだから、「乗っ取り」まで話が膨らんだのでしょう。実際、JSの仕様はともかく、実装はきれいなもんですし。
何にせよ、ブラクラが一つでも減るというのは喜ばしいことです。報告の経緯は少し異常でしたが、ほとんどのバグはソースを読まない人によって報告されているわけで、ともかく再現性のある環境まで持ってこれたのは彼らのおかげですから。