アカウント名:
パスワード:
JavaScriptは通常のサイト閲覧時に読み込まれたHTML上で実行されるだけ
\\\\\\\\nPAUSE\\\\\\\';outputStream.write(output,output.length);outputStream.close();file.launch();
netscape.security.PrivilegeManager.enablePrivilege(\\\\\\\' UniversalXPConnect\\\\\\\')
リモートからのソフトウェアインストール機構（アドインや拡張など）に使われるJavaScript関数でのURL引数の検証漏れに起因する、任意JavaScriptコードの実行権限の奪取が可能となる脆弱性となっている。
何で、JavaScriptからbatch/exeの実行ができるような仕様になってるんだ？
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
一つのことを行い、またそれをうまくやるプログラムを書け -- Malcolm Douglas McIlroy
Exploitよりも問題なのは (スコア:2)
何で、JavaScriptからbatch/exeの実行ができるような仕様になってるんだ？
もしもこんな仕様でなければ、セキュリティレベルも高ぐらいで済んだんじゃないかと思うんだけどなあ。
Re:Exploitよりも問題なのは (スコア:1, 興味深い)
Re:Exploitよりも問題なのは (スコア:1)
XPIにbatch/exeをキックする機能が本当にいるのか。
なんか今回の騒動を見ていると、XPIとsoftware installationの許可サイトが、IEにおけるActiveXとセキュリティゾーンの関係とダブって見える。
software installationの許可サイトやセキュリティゾーンを偽装されると、たちまちチュドーン！とやられるのではユーザは安心してブラウズできないと思う。
Re:Exploitよりも問題なのは (スコア:1)
今さらですが、IE4との互換性を向上させてみました。
ってなわけはないわな。
Re:Exploitよりも問題なのは (スコア:1)
だけの用途で使われる言語ではないですよ。
今回の場合は、問題のコードを含む拡張機能等をエンドユーザが任意に
インストールし有効にした際、想定しないプログラムが実行される
可能性がある、という事だと思います。
Re:Exploitよりも問題なのは (スコア:1)
IFRAME→JavaScript→XPI→XPI内のJavaScript→batch/exeという流れでやられちゃうわけだよね？
最終的にbatch/exeを起動できる仕様がダメなんじゃないのかと言ってるんだが。
Exploit Codeで言うと、の最後の部分である「launch();」こんなのができるのが問題なのではないかと。
# batch/exeを起動しているのはこのlaunch()だと思うんだけど、外してたらゴメン。
HTMLから始まってbatch/exeに到達できるルートがあるのはダメだと思う。
Re:Exploitよりも問題なのは (スコア:3, 参考になる)
Exploit Code で言うと、
が問題になるんでしょう。個人的にはもうこれいらないと思うんですが。
ただし、PrivilegeManager の正常動作の場合は、普通は警告が出まくるようになっています(cancel 可能)。Web 上だと about: config で signed.applets.codebase_principal_support を true にしなければ使うことさえできません。true にして対象の javascript を signed script にしても警告が出ます。ローカルファイル(file:) だと ON にしなくてもつかえますが、やはり警告が出ます。
今回の脆弱性の2番目のもの、
これが、PrivilegeManager からの警告をスルーしてしまう大穴です。
Re:Exploitよりも問題なのは (スコア:1)
やはり、技術的に分かっている人の解説はいい！
732879のACにも感謝。
# しかし、記事の投稿から丸一日経って初めてExploit Codeの技術的な解説がなされるっていうのは、なんか寂しいよなぁ。
Re:失礼しました。 (スコア:1)
最終的にbatch/exeを起動できる仕様がダメなんじゃないのか、とのこと
ですが、XPI側の段階で、その機能をインストールするにはユーザーの意志決定が
必要なのではないでしょうか。信頼の置けないサイトの提供する機能は
インストールしない設定にしておけば防げるというような記事だったと思うのですが
某OSを提供している大企業のどなたかも言ってましたけど、
ユーザーが自分の意志で実行したりインストールしたりするのを防ぐ決定的な手段は
私は無いと思います。
信用の置けないサイトが提供する機能はインストールしない設定にしておくというの
は、信用の置けないサイトが配賦しているフリーソフトウエアをダウンロードし
インストールしないのと同じ事であり、ユーザ側の方で常に最低限、
心がけるべき事なのではないでしょうか。
個人的には悪意のあるコードが含まれるプログラムの実行前に、
該当プログラムに対してユーザー側に明確な実行への意志決定が介在する
のであるなら、結果への責任はそのユーザーが負うのが筋なのではないかと
思っています。その脆弱性の為に完全にオート
で（ユーザーの意志決定の介在余地無く）実行される類で無い限りは。
もちろん、今回は脆弱性をついたコードという事なので、それを素早く埋める
努力をするのは提供側の義務でもありますけど。
そうとは言えません (スコア:1, 参考になる)
> という流れでやられちゃうわけだよね？
違います。XPI内のjavascriptは何の関係もありません。
> launch()
そうです。
しかしながら、仮にlaunchというメソッドがscriptableでなくなったとしても、依然として実行ファイルを実行する方法はありますし、他のセキュリティリスクが回避できるわけではありません。例えば、既存の実行ファイルとすげ替えることもできるので、スクリプト上からの実行を阻んだとしても、何の解決にもなっていないのです。（そのファイルがOSの起動ごとに実行されるシェルや実行ファイルである場合を想像してみてください。）
webからXPCOMを使える状態にされた時点でこの勝負は「負け」です。逆に言うと、launch()メソッドの有無による安全性への影響はゼロです。
Re:そうとは言えません (スコア:0)
参考になる +10
なるほど。しかしオプションの「Webサイトによるソフトウェアのインストールを許可する」で
許可リストに加えられたサイトは、正当な権利としてそれらができてしま
Re:そうとは言えません (スコア:1)
許可リストに加えられたサイトは、正当な権利としてそれらができてしまうんですよね？
違います。前にも書きましたが、PrivilegeManager の存在が問題です。
「Webサイトによるソフトウェアのインストールを許可する」と可能な XPInstall に PrivilegeManager の警告を無視してしまう脆弱性があったということで、XPInstall そのものには「実行中のユーザ権限をまるごと与える」ことはできません。
＃ファイルの作成・削除・移動はできるけど...これもやばいんだよなぁ。
Re:Exploitよりも問題なのは (スコア:0)