「IEとOEに任意コマンド起動の欠陥」記事へのコメント

問題なのは

[tix (7637)]

OBJECTタグのCODEBASE属性にコマンドのパス名を指定するだけで動いてしまうため、セキュリティ設定でアクティブスクリプトやActiveXを無効にしていても動いてしまう

これは正確ではありません。 object 要素の codebase 属性に任意のプログラムが指定できてしまうというのは既知の弱点で、 Force Feeding [ryukoku.ac.jp] （2000年6月）でも使われています。

Force Feeding のときは、別の弱点と組み合わせることで ActiveX も active scripting も無効な環境でも攻撃が成功してしまいましたが、今回の指摘も同様です。今回は The Pull 氏 [osioniusx.com]が active scripting が有効なら同じ弱点を突ける [rr.com]ことを示したことから発展して、 active scripting も無効でも同じ弱点を突けることを指摘しています。

なお、今回の弱点について、セキュリティホール memo [ryukoku.ac.jp] にも出ています。

--
鵜呑みにしてみる？

Re:問題なのは

[jbeef (1278)]

調べてみました。

object 要素の codebase 属性に任意のプログラムが指定できてしまうというのは既知の弱点で、

それも正確ではないようです。

まず、OBJECT要素のCODEBASE属性でコマンドを起動できるのは、仕様のようです。 ただし、それは、そのHTMLがローカルファイルである場合にだけです。 ローカルファイルに同様のHTMLを書いて開くと、現在でも再現します。（ローカルファイルのHTMLからコマンドを起動する方法は他にもあり、推測可能なパス名のファイルに任意のデータを置けてはならないというのは、Windowsの基本的なセキュリティ仕様です（これ以上は今は語れない…気づいた人もここではつっこまないで！）。）

「Force Feeding」の件の本質は、次の2点にあったようです。

1. 所定のディレクトリに任意のHTMLデータを置いて、 それを開かせることができてしまう。
2. 所定のディレクトリに任意の.exeファイルを置くことができてしまう。

そして、最近の発見の新しさは、

• The Pull氏の発見 [rr.com]によって、 DOMを使って動的に生成したHTMLは、 ローカルファイルのときと同様にOBJECTのCODEBASE属性のコマンドが呼び出されてしまうことが発覚した。
• GreyMagicの発見 [greymagic.com]によって、 Data Binding機能によりXMLで記述した文字列をHTMLに挿入したときも、同様に、 ローカルファイルのときと同様にOBJECTのCODEBASE属性のコマンドが呼び出されてしまうことが発覚した。

といったところかと。ですので、

Force Feeding のときは、別の弱点と組み合わせることで ActiveX も active scripting も無効な環境でも攻撃が成功してしまいましたが、今回の指摘も同様です。

より正確には、

• アクティブスクリプトが無効でも攻撃が成功してしまうのは、 OBJECTのCODEBASEでコマンドを呼び出すときの特徴で、 The Pull氏の発見では、スクリプトを使って動的にHTMLを生成するものだったのに対し、 今回の新しい方法は、Data Bindingを使っているため、スクリプトが不要になっている。
• Fource Feedingのときは、 所定の場所に任意のデータをローカルファイルとして置けてしまう問題だったので、 任意のコードを実行できてしまう問題だったが、今回の件ではそれはできない（既存のコマンドの起動しかできない）。

といったところかと。

ところで、 OBJECTのCODEBASEでは起動するコマンドに引数を渡せないのでたいした危険がない [2ch.net]とする説があるようですが、その点はどうでしょうか？

Re:問題なのは

[tix (7637)]

object 要素の codebase 属性に任意のプログラムが指定できてしまうというのは既知の弱点で、

それも正確ではないようです。

jbeef さんの書かれたとおりです。 HTML ファイルに object 要素を書いて codebase 属性に実行ファイルを指定したおいた場合、 HTML ファイルも実行ファイルもローカルにある場合は実行されますが、それ以外の組み合わせでは「未署名の ActiveX コントロールのダウンロード」を有効にしているかどうかで動作が決まります（実行ファイルが署名されていない calc.exe などの場合）。ローカルなファイルで実験していたため、勘違いしました。ご指摘ありがとうございます。

この動作が仕様だ、というのは、どこかに書かれているでしょうか。ご存知だったら教えてください。

ところで、 OBJECTのCODEBASEでは起動するコマンドに引数を渡せないのでたいした危険がないとする説があるようですが、その点はどうでしょうか？

「コマンドライン引数なしで起動できるプログラムはたいてい*対話型*のプログラムで、ユーザに何の確認もなしに危険な処理を行うことはないだろう」という意味ならそうかもしれません。もちろん可能なら回避策を施したほうが、安全とか快適という意味でよいと思いますが。

--
鵜呑みにしてみる？

回避方法

[AtmarkZero (7164)]

Proxomitronなどのローカルプロクシでフィルタリングするのが手っ取り早いかも。
と思っていたら、フィルタが用意されていました [dti.ne.jp]。パッチが出るまで、IEを使う必要がある場合はこれを使うのが確実でしょう。

Re:回避方法

[tix (7637)]

ポイントされているフィルタでは XML の CDATA セクションを検出して他の文字列に置き換えていますが、パターンマッチではじくなら datasrc 属性か xml 要素ではじくほうが安全です。

今回の弱点の発見者によるサンプルコードには CDATA セクションが使われていますが、このことは弱点とは関係がありません。 CDATA セクションを使わない例をここ [ryukoku.ac.jp]の最後に書いておきました。

Windows NT 系で使えると思われる回避法 [ryukoku.ac.jp]を示してみました。試すかたは自己責任で。

--
鵜呑みにしてみる？

Re:回避方法

[tix (7637)]

Advisory [greymagic.com] が更新されていて、 HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\0\1004 の値を DWORD 値の3に変更する（普通は0）という回避法が載っています。このほうがいい方法だと思うのでお勧めします。

セキュリティホール memo メーリングリスト [ryukoku.ac.jp]で教えていただきました。

--
鵜呑みにしてみる？

責任ある開示

[yourCat (4820)]

ローカルプロクシでフィルタリングするのが手っ取り早いかも。と思っていたら、フィルタが用意されていました。

発見した塞がれていないセキュリティー・ホールの公開は是か非かと問題 [srad.jp]になりますが、このようにフィルタを用意するなど回避手段があれば公開しやすいですね。当該製品の開発ベンダーが直してくれるまでは公開できない、でもなかなか直してくれないというジレンマが解決できます。
セキュリティー・ソフトのベンダーにも連絡すると、脆弱性を利用したワームの出現に備えた定義ファイルを用意しておけますね。なるほどなるほど。

#既に常識なのかな？

Re:回避方法

[POS (5608)]

ActiveScriptで動的に生成される場合には フィルターは効かないですよね

--
ぽ