アカウント名:
パスワード:
この件って、MS05-037とMS05-038と同じ、「IEで呼び出されることを前提に設計していないCOMオブジェクトをわざと呼び出すことでBuffer Overflowを引き起こす」ってやつだと思うんだけど、結局MS05-037とMS05-038の対策はレジストリに該当オブジェクトのGUIDでKillBitを設定して対策完了になってる。今回もそういうことになるだろう。
しかしだ、今回MS05-038で対策完了したと思ったら対策漏れのような感じでこの話が持ち上がった。今後もリストアップ漏れで対策が必要なオブジェクトが再び出てくる可能性は有りそうだし、詳しくないから分からないけど、MS以外のベンダが市販アプリケーションや顧客システム向けにCOMオブジェクトを独自開発しててそれがやばいということはないのだろうか。詳しい人どうなんでしょうか?
IEがKillBitの逆で、使いたいコンポーネントだけをレジストリに設定する設計だったらこんなことにはならなかったんだろうになぁと思ってますが。
同感ですね。javaprxy.dll (MS05-037) に関する @IT の記事によれば、SEC Consultによればほかにも20個近いCOMオブジェクトに同様の脆弱性があるとしている。 [atmarkit.co.jp]との事ですので。
MS以外のベンダが市販アプリケーションや顧客システム向けにCOMオブジェクトを独自開発しててそれがやばいということはないのだろうか。
COMオブジェクトはライブラリの一部ですから、当然のことながらあるでしょうね。ただ、攻撃者はどのライブラリなのかをGUIDか名前で指定する必要がありますから、インターネットからの不特定多数を相手にした攻撃の場合は「Microsoft以外の有名なベンダーであり、かつそのベンダーはネットワークやセキュリティに疎く、ごく普通の一般ユーザの環境にもインストールされるほどメジャーなソフトウエア」が真っ先に狙われるでしょう。 それ以外のマイナーなベンダーの場合は攻撃者が相手を特定して(メールで送りつけるなど)行なわれるでしょうね。
IEがKillBitの逆で、使いたいコンポーネントだけをレジストリに設定する設計
それってそもそもの ActiveX の思想を否定してしまいますよね。 実行しているプログラムが何の目的でどのように動いているのか、どのようにインストールするのかを全て省略し、Windowsが必要だと判断したときに自動で起動してやりとりするというのが ActiveX の発想の原点ですから、ユーザにそれらを管理させる(設定させる)というのは真逆の発想です。 そういう「ユーザに問い合わせない」発想の元に成り立っているシステムなので、インターフェイス仕様や依存関係も非開示になっていて、事実上ユーザに管理させることも不可能な実態になっていたりします。
よくあるパターンですが、WindowsからLinuxにユーザが移行したときに「あれが動かない、これが動かないのトラブルばかりに悩まされる」という苦労が語られますが、Windowsでユーザが気にしないうちにプログラムがダウンロードされて実行されているのは ActiveX の恩恵が強いがゆえに、それのないLinuxでは不便に感じてしまうというわけです。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
海軍に入るくらいなら海賊になった方がいい -- Steven Paul Jobs
完全対策は可能なのか? (スコア:3, 興味深い)
この件って、MS05-037とMS05-038と同じ、「IEで呼び出されることを前提に設計していないCOMオブジェクトをわざと呼び出すことでBuffer Overflowを引き起こす」ってやつだと思うんだけど、結局MS05-037とMS05-038の対策はレジストリに該当オブジェクトのGUIDでKillBitを設定して対策完了になってる。今回もそういうことになるだろう。
しかしだ、今回MS05-038で対策完了したと思ったら対策漏れのような感じでこの話が持ち上がった。今後もリストアップ漏れで対策が必要なオブジェクトが再び出てくる可能性は有りそうだし、詳しくないから分からないけど、MS以外のベンダが市販アプリケーションや顧客システム向けにCOMオブジェクトを独自開発しててそれがやばいということはないのだろうか。詳しい人どうなんでしょうか?
IEがKillBitの逆で、使いたいコンポーネントだけをレジストリに設定する設計だったらこんなことにはならなかったんだろうになぁと思ってますが。
Re:完全対策は可能なのか? (スコア:2)
> は有りそうだし
同感ですね。javaprxy.dll (MS05-037) に関する @IT の記事によれば、SEC Consultによればほかにも20個近いCOMオブジェクトに同様の脆弱性があるとしている。 [atmarkit.co.jp]との事ですので。
Re:完全対策は可能なのか? (スコア:1, 興味深い)
MS以外のベンダが市販アプリケーションや顧客システム向けにCOMオブジェクトを独自開発しててそれがやばいということはないのだろうか。
COMオブジェクトはライブラリの一部ですから、当然のことながらあるでしょうね。ただ、攻撃者はどのライブラリなのかをGUIDか名前で指定する必要がありますから、インターネットからの不特定多数を相手にした攻撃の場合は「Microsoft以外の有名なベンダーであり、かつそのベンダーはネットワークやセキュリティに疎く、ごく普通の一般ユーザの環境にもインストールされるほどメジャーなソフトウエア」が真っ先に狙われるでしょう。
それ以外のマイナーなベンダーの場合は攻撃者が相手を特定して(メールで送りつけるなど)行なわれるでしょうね。
IEがKillBitの逆で、使いたいコンポーネントだけをレジストリに設定する設計
それってそもそもの ActiveX の思想を否定してしまいますよね。
実行しているプログラムが何の目的でどのように動いているのか、どのようにインストールするのかを全て省略し、Windowsが必要だと判断したときに自動で起動してやりとりするというのが ActiveX の発想の原点ですから、ユーザにそれらを管理させる(設定させる)というのは真逆の発想です。
そういう「ユーザに問い合わせない」発想の元に成り立っているシステムなので、インターフェイス仕様や依存関係も非開示になっていて、事実上ユーザに管理させることも不可能な実態になっていたりします。
よくあるパターンですが、WindowsからLinuxにユーザが移行したときに「あれが動かない、これが動かないのトラブルばかりに悩まされる」という苦労が語られますが、Windowsでユーザが気にしないうちにプログラムがダウンロードされて実行されているのは ActiveX の恩恵が強いがゆえに、それのないLinuxでは不便に感じてしまうというわけです。
Re:完全対策は可能なのか? (スコア:1)
Microsoft謹製でもヤバい訳ですから、世間一般には「ネットワークやセキュリティに強い」と思われているベンダー、そう自負しているベンダーでも安心はできないと思いますよ。
外部機能のインストールから呼び出しまで自動化できるようになっている以上、危険が伴うのはあるいみ当然かも。
Re:完全対策は可能なのか? (スコア:0)