アカウント名:
パスワード:
タレコミでは脆弱性の詳細が不明だが、F-secureの同じページへリンクが張られていることからすれば 「Firefoxメモリコラプション脆弱性」 [f-secure.jp](SecuniaではMozilla Firefox Memory Corruption Vulnerability [secunia.com])と呼ばれているもののようだ。その記事によると
Firefox 3.5のこの脆弱性は、JavaScriptコード処理を行う際のエラーに起因する。詳細については、我々の脆弱性情報を参照して頂きたい。SBerryが発見したこのエクスプロイトは、昨日、よく知られたエクスプロイト・サイトに投稿された。
よく知られたエクスプロイトサイトといえば、milw0rm.org だろう。
2009-07-13 Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit [milw0rm.org] HITS:24451
デモページ（http://www.milw0rm.org/exploit.php?id=9137）も準備されているので、現時点で最新のナイトリー(
毎度水を差すようで悪いとは思うんですが、
件のPoCではまずJavaScriptコードで、シェルコード（calc.exe起動）を含む約.375MBの文字列×600個の配列（単純計算でも最低約225MB）を作成しています。これは脆弱性を突いたときのコード実行の成功確率を高めるためで[*]、そうしておいてからJSエンジンの脆弱性（FONT要素の扱い）を突くJSコードを実行し、メモリ破壊を引き起こして先のシェルコードを実行するようになっています。 [*] 参考: MYCOMの記事PoCの内側 - Heap Spray(1) [mycom.co.jp], (2) [mycom.co.jp]）。
配列作成にはメモリを大量に消費しますし（環境にも寄るでしょうが）結構時間が掛かりますが、脆弱性を突く部分（その関数を呼び出す99行目もしくは100行目）を削るだけでメモリ破壊（クラッシュ）は起きません。逆に、メモリ破壊を起こすだけなら配列作成の部分（25-52行目）は要りませんし、メモリ大量消費は起こりません。
で、スクリプト実行が長時間続いたときの中断ダイアログが出て止めることができた/メモリを食い尽くしてフリーズというのは、まだ仕込みの段階で脆弱性を突くところまで行ってなかったのではないかと思います。せめて中断しなかった場合はどうか、自環境のメモリ量にあわせ配列を調整した場合はどうかなどを見ないと、試したことにはならないですよ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
コンピュータは旧約聖書の神に似ている、規則は多く、慈悲は無い -- Joseph Campbell
Exploit公開中 (スコア:1, 参考になる)
「未対策の脆弱性が発見」というだけでなく、「攻撃方法も公開中」であることを
考慮した上で、ユーザは対応しましょう。
Exploitのデモページを試してみました(w (スコア:2, 参考になる)
タレコミでは脆弱性の詳細が不明だが、F-secureの同じページへリンクが張られていることからすれば 「Firefoxメモリコラプション脆弱性」 [f-secure.jp](SecuniaではMozilla Firefox Memory Corruption Vulnerability [secunia.com])と呼ばれているもののようだ。その記事によると
よく知られたエクスプロイトサイトといえば、milw0rm.org だろう。
2009-07-13 Mozilla Firefox 3.5 (Font tags) Remote Buffer Overflow Exploit [milw0rm.org] HITS:24451
デモページ（http://www.milw0rm.org/exploit.php?id=9137）も準備されているので、現時点で最新のナイトリー(
モデレータは基本役立たずなの気にしてないよ
Re:Exploitのデモページを試してみました(w (スコア:3, 興味深い)
毎度水を差すようで悪いとは思うんですが、
件のPoCではまずJavaScriptコードで、シェルコード（calc.exe起動）を含む約.375MBの文字列×600個の配列（単純計算でも最低約225MB）を作成しています。これは脆弱性を突いたときのコード実行の成功確率を高めるためで[*]、そうしておいてからJSエンジンの脆弱性（FONT要素の扱い）を突くJSコードを実行し、メモリ破壊を引き起こして先のシェルコードを実行するようになっています。
[*] 参考: MYCOMの記事PoCの内側 - Heap Spray(1) [mycom.co.jp], (2) [mycom.co.jp]）。
配列作成にはメモリを大量に消費しますし（環境にも寄るでしょうが）結構時間が掛かりますが、脆弱性を突く部分（その関数を呼び出す99行目もしくは100行目）を削るだけでメモリ破壊（クラッシュ）は起きません。逆に、メモリ破壊を起こすだけなら配列作成の部分（25-52行目）は要りませんし、メモリ大量消費は起こりません。
で、スクリプト実行が長時間続いたときの中断ダイアログが出て止めることができた/メモリを食い尽くしてフリーズというのは、まだ仕込みの段階で脆弱性を突くところまで行ってなかったのではないかと思います。せめて中断しなかった場合はどうか、自環境のメモリ量にあわせ配列を調整した場合はどうかなどを見ないと、試したことにはならないですよ。