IEとOEに任意コマンド起動の欠陥

jbeef曰く、"さきほどBUGTRAQに流れた情報によると、 Windows版Internet Explorerに、ローカルにある任意のコマンドを起動できるセキュリティホールが見つかったとのこと。cmd.exeやtftp.exeを起動するなどすれば、ありとあらゆる悪さができてしまう。ウィルスに応用される危険性も現実的と思われる。 これはIEをHTMLメール表示に使用している、Outlook、Outlook Express等も同様に影響される。 発見者の説明にあるように、OBJECTタグのCODEBASE属性にコマンドのパス名を指定するだけで動いてしまうため、セキュリティ設定でアクティブスクリプトやActiveXを無効にしていても動いてしまう。これはかなり深刻だ。

先月発覚した、ソニーVAIOのセキュリティホールも任意のコマンドを起動できてしまう問題だった。このときは、ソニーは、それを深刻な問題と受け止め、責任を持ってユーザへの告知を徹底して行ってくれたが、今回のように、OEMとして販売しているWindowsに同等以上の欠陥が見つかった場合にも、パソコン販売メーカーは、同じようにユーザへの告知を徹底すべきではないだろうか。"

問題なのは

[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で動的に生成される場合には フィルターは効かないですよね

--
ぽ

そんなわきゃーない！

[Transponder (6045)]

OEMとして販売しているWindowsに同等以上の欠陥が見つかった場合にも、パソコン販売メーカーは、同じようにユーザへの告知を徹底すべきではないだろうか。

「弊社の販売しているPCに搭載していたMSのIEですが、あまりの問題の多さに弊社も辟易しました。この度、ユーザの皆様にはとてもお勧めできるものではないと弊社は判断いたしましたので、IE以外のブラウザをお使いください。」
とか、ニュースリリースが出たりして

--

# I will work seriously this year!

ISP中には

[SAY (54)]

　親会社がPCを販売しててIEやOEがデフォルトで代替手段も提供していないのにISP側ではフィルタリングサービスを金をとって提供しているところもあるし。
　まるで某社の自らの欠点を新たな商売のネタとする手法を踏襲するようなやり口に感心します。

Re:ISP中には

[riot (719)]

まるで某社の自らの欠点を新たな商売のネタとする手法を踏襲するようなやり口に感心します。

う～ん、気持ちは分りますけど、そう断定的なのもどうかと思いますが。(元発言はもちろん皮肉ですよね？)

現代って、一分野だけで商売って成立ち難いですし、販売会社もISPも「これはウチの仕事か？」と思うこともやらなくてはならないのでしょう。
その上で、予算は何処かしらから調達しなくてはならないわけで。
そういう意味では、いたしかたないとも思えます。
「金は払ってやるから、手前の方でやってくれ」って人は少なくないですからねぇ。

ただ、ISPがフィルタリングサービスをしないといけないような製品が標準であり、それが市場を事実上独占してるうえ、利用者の多くが代替手段を知らないということには、それこそ感心してしまいますが。
なんか、何処が悪いとかじゃないように思えてなりませんよ、最近の世の中。

おいおい

[Anonymous Coward]

悪いのはＭＳじゃん。
なんでプロバイダにやつあたりする？

Re:おいおい

[Anonymous Coward]

MSとISPが裏で手を組んでいるという疑念が湧いているのでは。

Re:おいおい

[Anonymous Coward]

良くプロバイダのCDROMにIEがはいってるジャン(笑)

結構キレイにまとまっているサイト

[atrib (5512)]

本セキュリティホールに関してキレイにまとまっているサイトがありました(via 「hardでloxseな日々」 [papalagi.org])

http://homepage2.nifty.com/m_kamada/javascript/ietest7.htm [nifty.com]

私の様なヒヨッコには非常に有り難い情報満載でした。ご参考までに。

欠陥って…

[Anonymous Coward]

OEMとして販売しているWindowsに同等以上の欠陥が見つかった場合にも

Windows自体が欠陥商品なので、それ自体OEMで販売することが問題になりゃせんだろうか？

最近

[Anonymous Coward]

/.にログインして参加しようとするとコメント出来なかったり、日記が書けなかったりしますが、それもそのバグが原因である可能性はあるんでしょうかね。ログインして書けないから、仕方なくAC使ってるんだけど。

Re:最近

[Anonymous Coward]

ポストか赤く見えてしまうのもそのバグが原因である可能性があります:-p