FlashのActiveXプラグインに脆弱性 23
ストーリー by yourCat
賽の河原でもぐら叩き 部門より
賽の河原でもぐら叩き 部門より
k3c曰く、 "BugTraqへの投稿によれば、Macromedia FlashのActiveXプラグインであるFlash.ocxのバージョン6.0r23以前にバッファオーバーフローの脆弱性があり、この脆弱性を突いたコードを含んだHTMLをIEで表示させる (Outlook ExpressなどIEコンポーネントを使った他のプログラムでもよい) ことで、FlashのActiveXプラグインを通してそのコードを実行させることができるそうです。Macromediaからは既に対策済みのバージョン (6.0r29) がダウンロードできます。
以前、Flashムービー形式のウイルスというのをタレコみましたが、これは感染にFlashプレイヤーが必須だったのに対して、今度の脆弱性はIEのFlashプラグインがあれば被害を受けます。IEのインストーラでオプションとしてインストールできたり、Windows Updateでインストールを勧められたりするプラグインであり、最近ではWebでの広告媒体としても用いられはじめたのですが…Flashよ、お前もか。"
"この種の問題に対する根本的な対策としては、いつも言われることですが、IEのセキュリティ設定を変更して、ActiveXコントロールのダウンロードや実行を無効にすること、でしょう。なお、Flash.ocxが自分のPCにインストールされていないか検索などで確認し、もしインストールされていればバージョンアップしておくこともオススメしておきます。(投稿を読むと、削除は安全な選択肢とは言えないような気がしますがどうなんでしょう。) ちなみにワタシのPCにはばっちりインストールされてました…とりあえず速攻でバージョンアップしてきましたとも。"
プリインストールパソコン製造者の責任 (スコア:5, 参考になる)
バージョン5 (スコア:1)
こんな昔のだと、ほかにも弱点なかったっけ？（汗）
調べてみたら、バージョン5にもバッファオーバーフローはあるみたいです。
なお、バージョン5ではファイル名が swflash.ocx だったようです。最新バージョン 6.0 r29 をインストールしても、 C:\WINNT\system32\Macromed\swflash.ocx が残りました。ファイルだけ残っていても ActiveX コントロールとしては使えないはずなので大丈夫なはずですが、気持ちが悪いので手で削除しました。ただ、ひょっとすると最新のバージョンをインストールしたときに swflash.ocx が使用中だったかもしれず、そのせいで自動的に削除できなかった可能性もあります。
断定的なことを何も書いてない……けれど、これだけははっきりしています: ソフトはちゃんと更新しましょう。
鵜呑みにしてみる？
Re:バージョン5 (スコア:2, 参考になる)
swflash.ocx が残っていると、これが出ちゃうみたいですね。
僕も両方削除してダウンロードしなおしましたが
Flash.ocx のタイムスタンプは同じでした。
両方あると、コンテンツによってはバージョン5が使われるということか。
> ひょっとすると最新のバージョンをインストールしたときに swflash.ocx が使用中だったかもしれず、そのせいで自動的に削除できなかった可能性もあります。
ダウンロードページでは、大々的に Flash 使ってますよね（ページの右横）。
このページのツールバーは Flash じゃなくあえて GIF みたいだけど
これって平気なのん？
Re:バージョン5 (スコア:1)
regsvr32.exe /u swflash.ocx
とでもすればOKでしょうか？＞識者の皆様。
念のために、Renameしとくと良いかも。
あ、登録しなおすときは
regsvr32.exe /i swflash.ocx
で、大丈夫*だと*思います(おぃ
# いつものことだけど、無保証です。
# まだ思いついただけで実行してませんし(ぉぃ*10
重要:上記の手順を実行する前に・・・ (スコア:1)
「プログラムの追加と削除」
にShockWaveあたりであるかもしれないし、
「Windowsコンポーネントの追加と削除」
にあるかもしれないし、
「ツール」＞「インターネット オプション」
「インターネット 一時ファイル」枠内の「設定」
「インターネット一時ファイルのフォルダ」枠内の
「オブジェクトの表示」にあるかもしれない。
というわけで、
regsvr32.exe を使うのは最終手段ということで。
Re:バージョン5 (スコア:0)
5.0r42が入ったのだけどどういうこと?
Windows2000 Professional + SP2
IE5.5SP2
それぞれパッチ済み
http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash-jp.html
から自動インストール
(元のバージョンは6.0r23だったので新しいのに置き換わるかと
思ったら、何の変更も無かったので、一旦ocxを削除)
Re:バージョン5 (スコア:1)
鵜呑みにしてみる？
Re:バージョン5 (スコア:1)
鵜呑みにしてみる？
Re:バージョン5 (スコア:0)
IEのセキュリティで、www.macromedia.comを信頼ゾーンに設定
していたのだけど(インターネーットゾーンはほとんど機能off)
Flash自体はdownload.macromedia.comからやってくるようで、
*.macromedia.comを信頼すると問題なくインストールできました。
しかし、自分の設定ミスなんだけど古いバージョンが入るのは、うむむ、、、
Re:バージョン5 (スコア:0)
ですべてのShockwave Playerをいったんアンインストールしてから
最新バージョンをインストールしてはどうでしょう？
http://download.macromedia.com/pub/shockwave/uninstall/win/SW8.5.1_uninstall.exe
やっぱjavaか?(弱気発言) (スコア:1)
聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
(弱気にも)思ってしまったりするんですが、どうなんでしょう?
メジャーなものでそれっぽいものといえば一番に思いだされるのはjavaっすかね。
#ん?MSもC#にソレを期待しているんだろうか???違うかな?
「どうなんでしょう?」ってのは、javaみたいなやりかたでもやっぱり
こういうトラブルは起きるものなんだろうか?という意味(の便乗質問)でして(^^;、
そういやjavaとかで出来たソフトでこういうトラブルを起こした話って
実際聞いたことが無いような気がします。
それとも俺が無知なだけか、さもなくば事例の分母が少ないので世間で見いだされてないだけか、
とかいうものなんでしょうか、ね?
いや、つまるところ乱暴にいえば、「なんでまだC(++)で書いてるの?」という遠回しの質問でもあります(^^;;;;;;;;;;;;;;
Re:やっぱjavaか?(弱気発言) (スコア:2, 参考になる)
「Web 配信プログラムとか（のセキュリティ穴の話）」というのが何を指しているのかわかりませんが、 CGI プログラムのことを言っているなら、大きな問題は設計のバグと cross-site scripting で、どちらも Java の言語機構で防ぐことはできないと思います。
Java が安全だというのは、たいてい「悪意のある（実行者が信頼していない）アプレットを実行してしまっても安全」という意味です。 Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり、その点に関しては Java の（Perl などに対する）セキュリティの面での優位性はないでしょう。
C/C++ ではポインタの演算・変換が自由なので、セキュリティはプログラマの注意力にかかっています。個人的には C/C++ はアプリケーション開発に不向きだと思いますが、ソフトウェアの開発のための言語として C/C++ を採用することは既存のライブラリや既存のプログラマや既存の教育方法 :) を使えるというメリットがあります。言語仕様がこの先簡単には変わらないだろうというのもメリットかもしれません。
鵜呑みにしてみる？
Re:やっぱjavaか?(弱気発言) (スコア:1)
了解です。つーかこっちも「java「とか」」というように
対象を特定しないように書いてあったのは、そういう意図からです。
べつにrubyでもschemeでも良いと思います。
>CGI プログラムのことを言っているなら
半分はご指摘のとおりです。
のこり半分は、アプレットとかのクライアントサイドで動くモノの話。
今回話題のActiveXもソレですよね。
>Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり
…どうなんでしょうね…
そもそも頁の部品かどうかってのは、「規模」の問題ではない(はずだ)し…
>既存の教育方法 :) を使えるというメリット
うぎゃーーー(笑)
>言語仕様がこの先簡単には変わらないだろう
javaあたりはこれを満たすことが期待できないかなーとか思ったりはします。
Sunが強権(よりによって不評な点ですが)で言語仕様を堅持してるわけですから。
#まあ勿論、標準化なんたら委員会でもいいんですが…
Re:やっぱjavaか?(弱気発言) (スコア:1)
では、どうして Flash Player は Java アプレットとして書かれていないか、といえば、 Flash Player は Java VM と同列に並ぶものであることを狙っているからです。 Java VM さえ安全なら、知らないアプレットでも安全に動かすことができるのと同じように、 Flash Player さえ安全なら、知らない Flash ムービーを安全に再生することができます。
つまり、安全性の保証がツリー構造になっているわけです。安全性を保証するツリーのルートがあまりたくさんあると意味がありませんが、一つしかないのも危険です。
できれば、 Java アプレットとして書かれた Flash Player という選択肢も用意してあったら、 Macromedia の書いたプログラムを信頼したくないという人も安心できるのですが、ぼくが考えるに、ネイティブな Flash Player のほうが重要です。
逆に Flash ムービーとして書かれた Java VM があったら、 Java VM のメーカを信頼しなくても安全に Java アプレットが使えるけど……。
// Flash のことを全然知らないのですが、無理ですよね？＞ Flash に詳しいかた
鵜呑みにしてみる？
Re:やっぱjavaか?(弱気発言) (スコア:1)
そうですね。
>アプレットを信頼していなくても安全に実行できる点で VM＋中間コード
こっちについてはどうでしょうか?
これまたrubyやschemeでも同じことが言えるのではないかと。
スクリプトのインタプリタってのはいわばテキストをコードとするVMです(笑)から…
>安全性を保証するツリーのルートがあまりたくさんあると意味がありませんが、一つしかないのも危険です。
え? ここでいう危険度は、それ(ら)が1つきりか複数か?に相関する事柄では、ないのではないですか?
確率的な攻撃者(^^;から見れば「どれか1個所が」穴あいていれば攻撃が成立しちゃうわけですから、
1つだから危険度が増す、などと考える暇は無いんじゃないかと思うのですが。
むしろ、1つだからそこさえ固めれば死なずに済む、というメリットとして機能することのほうが
考えやすいかと…
>Flash ムービーとして書かれた Java VM があったら、 Java VM のメーカを信頼しなくても安全に Java アプレット
当然ですが、それとてFlashPlayerが壊れていればアウトであるわけですよね。
Re:やっぱjavaか?(弱気発言) (スコア:1)
鵜呑みにしてみる？
えーと (スコア:1)
Re:えーと (スコア:1)
それは、手間の「数」の問題かと。
ライブラリというものの存在意義(おおげさか)に関わる話ですが、
その「一箇所を」直せば全部直るという側面があるわけですよね。
JVM「さえ」直せばOKという面が。
アプリ(?)側でのテストのやりなおしという代償は有りますが、
テストの手間は、問題発生個所が分散していようがいまいが
乱暴にいえば同じなわけですから、気にしても意味がない。
また、
>結局OSから全部セキュア
たとえばVMがOSの不都合を「ラップ」するように作る、ということもできるわけですよね。
#効率とか色々な面で馬鹿げた選択と言えてしまう場合「も」有るとはいえ。
下層のOSから見ても、上層のアプリ(?)から見ても、ものごとがいったん「一点」に集約
してしまうってのが、VMってものの強み(活かせるならば)ですよね。
で、逆に、
旧来(^^;のように、修正必要個所が分散していたら、どうなんでしょう?
それって世間でよく言うような「リスク分散」に、なっているんでしょうか?
プログラムはしばしば複数が協調して動く必要が有り、そのどれもが
完全(ってのか)であることを求められるわけです(よね)から、
修正個所を分散しても、ちっとも「リスク分散」したことに成らないと、思うのです。
つまり、VMってものの有りようは、弱みよりも強みとして顕在化することのほうが「多い」のではないか?と、愚考するのですがどうでしょうか?
Re:えーと (スコア:2, すばらしい洞察)
Re:えーと (スコア:1)
でも実行を制限する機能を持ってないので、VM より実現できることが少ないですね。
VM なら個々の動作ごとにやだって言えるタイミングがあるけど、ActiveX は一旦実行させてしまうと手を出せない。
Re:やっぱjavaか?(弱気発言) (スコア:1)
> 聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
> ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
> (弱気にも)思ってしまったりするんですが、どうなんでしょう?
そんな事は無いと思う。
Cだってセキュアな記述をしようとすれば出来る。>根絶できる
それはjavaとかとは難易度が低いか高いかの差であって、javaだからボケたプログラムでOKって訳じゃないよね。
javaで楽できるからって程度の低いプログラマでいい訳じゃないし、
それがC(++)でプログラムするなって事にはならないでしょ？
「なんでまだC(++)で書いてるの?」ってそりゃそっちの方が楽だから。
javaの方が楽できればjavaで書くべし。
streamのparseなんかをjavaとCで書き比べてみれば、
程度にもよるけどCの方が半分くらいのコード量で済むんじゃないかな？
# javaよりCの方が実行速度が速い訳ではなくって、
# (Cで書くよりも何倍も)苦労すれば速度差はそれほどないです。
要は労の少ない選択をして、
適切な苦労のかけどころに、適切な苦労をする事でしょ:-)
Re:やっぱjavaか?(弱気発言) (スコア:1)
その差を無視できないことを以って「(理学ではなく)工学的である」と言う、とか聞いたような記憶が有ります。
つまりゲンジツ的であるかどうかという事。
現にこれだけ事実として事故が起きているのですから、無視できないのでは?
>javaだからボケたプログラムでOKって訳じゃない
極論すればそれは「ボケる余地すら無い」かどうかの問題ですよね。
つまり1行も書かないのがバグが出ない一番の手であり、
javaのような(Cよりは高級な)言語で書けば、ある場面において、
Cでならば「書かないとならない」がjavaだと「書く必要が無い」
(ときとして「書くことが不可能」ですらある)、ということが有るわけで、
バグの量はそこで差がつくわけです。
#それ以外の場面では、当然ですが技量の差が直接出るはずです(^^;
>そりゃそっちの方が楽だから。
(俺が)Cのほうが楽だなと思える場面といったら、
文字列のコード(の変換)について考えなくて済む(まさに上記参照…)場面と、
byte(?)配列の操作がゴリゴリ直感的に書けるという場面、だけ、
のような気がしています(^^;
#配列といえば、java1.4にはBufferとかいうクラスが増えたそうですね。
#いままでBufferdHogehogeは有ったけど、その相方たるBufferそのものは暗黙化されていて不便だった、と…
Cをどう思うか?は、文字列そのものとか生byte配列とかを頼る率の多寡に、依存するかもと思います。
データの構造化がもっと華々しくなると、Cみたいなのだとキツい…
>streamのparse
StreamTokenizer(ぉ
parseそのものはともかく、そのparseの結果として生じる状態とかの管理が
ややこしくなると、非OO(=状態の管理単位を整理しにくい)だったり非GC(^^;だったりする言語では、辛いです…
>要は労の少ない選択をして
では、Cでセキュアなプログラムを(セキュアさが必要とされる場面で)書くことは、
どれくらい労が少ないと言えるのでしょうか?(^^;;;;
追加情報 (スコア:1)