パスワードを忘れた? アカウント作成
2934 story

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にはばっちりインストールされてました…とりあえず速攻でバージョンアップしてきましたとも。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by jbeef (1278) on 2002年05月04日 15時33分 (#89525) 日記
    Windowsインストール済み「パソコン」を製造販売しているメーカー各社は、自社の製品が、Flash、QuickTime、Acrobat Readerなどのプラグインをインストールした状態で出荷されているかどうかを公表して欲しいですね。そして、入れているのなら、こうした脆弱性の発覚時に、アップデートを促す告知をして欲しいものです。購入した後でユーザが自発的にインストールしたものについては自己責任と言えるでしょうが、何が最初から入ってるかなんて知らない人がほとんどでしょう。Windows本体については脆弱性情報の伝達がだいぶ徹底されるようになってきた昨今、あとは、プリインストールという行為の主体である、パソコンメーカの責任が問われるのではないかと。
  • by tix (7637) on 2002年05月04日 10時58分 (#89490) ホームページ
    見てみたら、バージョン5が入っていました。
    こんな昔のだと、ほかにも弱点なかったっけ?(汗)

    調べてみたら、バージョン5にもバッファオーバーフローはあるみたいです。

    なお、バージョン5ではファイル名が swflash.ocx だったようです。最新バージョン 6.0 r29 をインストールしても、 C:\WINNT\system32\Macromed\swflash.ocx が残りました。ファイルだけ残っていても ActiveX コントロールとしては使えないはずなので大丈夫なはずですが、気持ちが悪いので手で削除しました。ただ、ひょっとすると最新のバージョンをインストールしたときに swflash.ocx が使用中だったかもしれず、そのせいで自動的に削除できなかった可能性もあります。

    断定的なことを何も書いてない……けれど、これだけははっきりしています: ソフトはちゃんと更新しましょう。
    --
    鵜呑みにしてみる?
    • Re:バージョン5 (スコア:2, 参考になる)

      by singha (7554) on 2002年05月04日 11時53分 (#89498) 日記
      うちでも、Upgrade 後のバージョン確認で 5.x と表示するのをしました。
      swflash.ocx が残っていると、これが出ちゃうみたいですね。

      僕も両方削除してダウンロードしなおしましたが
      Flash.ocx のタイムスタンプは同じでした。
      両方あると、コンテンツによってはバージョン5が使われるということか。

      > ひょっとすると最新のバージョンをインストールしたときに swflash.ocx が使用中だったかもしれず、そのせいで自動的に削除できなかった可能性もあります。

      ダウンロードページでは、大々的に Flash 使ってますよね(ページの右横)。
      このページのツールバーは Flash じゃなくあえて GIF みたいだけど
      これって平気なのん?
      親コメント
      • by kei100 (5854) on 2002年05月04日 23時51分 (#89622)
        とりあえず、
        regsvr32.exe /u swflash.ocx
        とでもすればOKでしょうか?>識者の皆様。

        念のために、Renameしとくと良いかも。

        あ、登録しなおすときは
        regsvr32.exe /i swflash.ocx

        で、大丈夫*だと*思います(おぃ

        # いつものことだけど、無保証です。
        # まだ思いついただけで実行してませんし(ぉぃ*10
        親コメント
        • よく考えたら、
          「プログラムの追加と削除」
          にShockWaveあたりであるかもしれないし、
          「Windowsコンポーネントの追加と削除」
          にあるかもしれないし、
          「ツール」>「インターネット オプション」
          「インターネット 一時ファイル」枠内の「設定」
          「インターネット一時ファイルのフォルダ」枠内の
          「オブジェクトの表示」にあるかもしれない。

          というわけで、
          regsvr32.exe を使うのは最終手段ということで。
          親コメント
    • by Anonymous Coward
      ダウンロードしに行ったら、6.0r29じゃなくて
      5.0r42が入ったのだけどどういうこと?

      Windows2000 Professional + SP2
      IE5.5SP2
      それぞれパッチ済み

      http://www.macromedia.com/shockwave/download/triggerpages_mmcom/flash-jp.html
      から自動インストール

      (元のバージョンは6.0r23だったので新しいのに置き換わるかと
      思ったら、何の変更も無かったので、一旦ocxを削除)
      • by tix (7637) on 2002年05月06日 14時37分 (#89944) ホームページ
        ぼくはここ [macromedia.com]からダウンロードしたらバージョン6になりました。参考までに。
        --
        鵜呑みにしてみる?
        親コメント
        • by tix (7637) on 2002年05月06日 15時15分 (#89950) ホームページ
          と思ったけど、同じページのことを言っていました。すみません。うーん、何なのでしょう?
          --
          鵜呑みにしてみる?
          親コメント
          • by Anonymous Coward
            すみません。しょうもない理由でした。

            IEのセキュリティで、www.macromedia.comを信頼ゾーンに設定
            していたのだけど(インターネーットゾーンはほとんど機能off)
            Flash自体はdownload.macromedia.comからやってくるようで、
            *.macromedia.comを信頼すると問題なくインストールできました。

            しかし、自分の設定ミスなんだけど古いバージョンが入るのは、うむむ、、、
    • by Anonymous Coward
      Shockwave Player アンインストーラー
      ですべてのShockwave Playerをいったんアンインストールしてから
      最新バージョンをインストールしてはどうでしょう?
      http://download.macromedia.com/pub/shockwave/uninstall/win/SW8.5.1_uninstall.exe
  • by G7 (3009) on 2002年05月04日 12時44分 (#89502)
    バッファオーバーフローとかweb配信プログラムとか(のセキュリティ穴の話)を
    聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
    ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
    (弱気にも)思ってしまったりするんですが、どうなんでしょう?

    メジャーなものでそれっぽいものといえば一番に思いだされるのはjavaっすかね。
    #ん?MSもC#にソレを期待しているんだろうか???違うかな?

    「どうなんでしょう?」ってのは、javaみたいなやりかたでもやっぱり
    こういうトラブルは起きるものなんだろうか?という意味(の便乗質問)でして(^^;、
    そういやjavaとかで出来たソフトでこういうトラブルを起こした話って
    実際聞いたことが無いような気がします。
    それとも俺が無知なだけか、さもなくば事例の分母が少ないので世間で見いだされてないだけか、
    とかいうものなんでしょうか、ね?

    いや、つまるところ乱暴にいえば、「なんでまだC(++)で書いてるの?」という遠回しの質問でもあります(^^;;;;;;;;;;;;;;
    • by tix (7637) on 2002年05月04日 13時24分 (#89512) ホームページ
      バッファオーバーフローについては、ポインタの自由な演算を許さず、配列の添え字を検査する言語であれば起きないので(たぶん)、 Java 以外でも Perl など多くの言語で防げます。 Perl は怪しいことをすればいくらでも怪しいことができるので例が悪いかもしれませんが。

      「Web 配信プログラムとか(のセキュリティ穴の話)」というのが何を指しているのかわかりませんが、 CGI プログラムのことを言っているなら、大きな問題は設計のバグと cross-site scripting で、どちらも Java の言語機構で防ぐことはできないと思います。

      Java が安全だというのは、たいてい「悪意のある(実行者が信頼していない)アプレットを実行してしまっても安全」という意味です。 Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり、その点に関しては Java の(Perl などに対する)セキュリティの面での優位性はないでしょう。

      C/C++ ではポインタの演算・変換が自由なので、セキュリティはプログラマの注意力にかかっています。個人的には C/C++ はアプリケーション開発に不向きだと思いますが、ソフトウェアの開発のための言語として C/C++ を採用することは既存のライブラリや既存のプログラマや既存の教育方法 :) を使えるというメリットがあります。言語仕様がこの先簡単には変わらないだろうというのもメリットかもしれません。
      --
      鵜呑みにしてみる?
      親コメント
      • by G7 (3009) on 2002年05月04日 13時49分 (#89518)
        >Java 以外でも Perl など

        了解です。つーかこっちも「java「とか」」というように
        対象を特定しないように書いてあったのは、そういう意図からです。
        べつにrubyでもschemeでも良いと思います。

        >CGI プログラムのことを言っているなら

        半分はご指摘のとおりです。

        のこり半分は、アプレットとかのクライアントサイドで動くモノの話。
        今回話題のActiveXもソレですよね。

        >Web ページの部品という規模より大きなアプリケーションを動かすためには、そのアプリケーションを信頼する必要があり

        …どうなんでしょうね…
        そもそも頁の部品かどうかってのは、「規模」の問題ではない(はずだ)し…

        >既存の教育方法 :) を使えるというメリット

        うぎゃーーー(笑)

        >言語仕様がこの先簡単には変わらないだろう

        javaあたりはこれを満たすことが期待できないかなーとか思ったりはします。
        Sunが強権(よりによって不評な点ですが)で言語仕様を堅持してるわけですから。
        #まあ勿論、標準化なんたら委員会でもいいんですが…
        親コメント
        • ぼくが
          やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
          ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
          を受けてこのコメント [srad.jp]を書いたのは、「バッファオーバーフローを防ぐ」という観点で Java が安全なのは「非 native コードかつセキュリティモデルに囲われたモノ」だからではない、と言いたかったからです。
          つーかこっちも「java「とか」」というように
          対象を特定しないように書いてあったのは、そういう意図からです。
          べつにrubyでもschemeでも良いと思います。
          であれば、なおさら VM を使っていることは無関係ですよね。
          のこり半分は、アプレットとかのクライアントサイドで動くモノの話。
          こちらについては、アプレットを信頼していなくても安全に実行できる点で VM+中間コードという形態が優れています。

          では、どうして 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 に詳しいかた
          --
          鵜呑みにしてみる?
          親コメント
          • by G7 (3009) on 2002年05月10日 2時10分 (#91320)
            >VM を使っていることは無関係

            そうですね。

            >アプレットを信頼していなくても安全に実行できる点で VM+中間コード

            こっちについてはどうでしょうか?
            これまたrubyやschemeでも同じことが言えるのではないかと。
            スクリプトのインタプリタってのはいわばテキストをコードとするVMです(笑)から…

            >安全性を保証するツリーのルートがあまりたくさんあると意味がありませんが、一つしかないのも危険です。

            え? ここでいう危険度は、それ(ら)が1つきりか複数か?に相関する事柄では、ないのではないですか?
            確率的な攻撃者(^^;から見れば「どれか1個所が」穴あいていれば攻撃が成立しちゃうわけですから、
            1つだから危険度が増す、などと考える暇は無いんじゃないかと思うのですが。

            むしろ、1つだからそこさえ固めれば死なずに済む、というメリットとして機能することのほうが
            考えやすいかと…

            >Flash ムービーとして書かれた Java VM があったら、 Java VM のメーカを信頼しなくても安全に Java アプレット

            当然ですが、それとてFlashPlayerが壊れていればアウトであるわけですよね。
            親コメント
            • え? ここでいう危険度は、それ(ら)が1つきりか複数か?に相関する事柄では、ないのではないですか?
              弱点が発見されたときにメーカがすぐに修正できるなら、 G7 さんのおっしゃる通りです。しかし、ある実装に危険があってもすぐに修正されるとは限らず、等価な実装が複数あれば利用者は被害に遭う前に他の実装に乗り換えることができます。
              むしろ、1つだからそこさえ固めれば死なずに済む、というメリット
              を否定するつもりはありませんが、それだけではいけません。
              >Flash ムービーとして書かれた Java VM があったら、……
              当然ですが、それとてFlashPlayerが壊れていればアウトであるわけですよね。
              そうです。
              --
              鵜呑みにしてみる?
              親コメント
    • by take0m (4948) on 2002年05月04日 13時01分 (#89507) 日記
      たとえば、ここ [impress.co.jp]にありますように、JavaだってVMにバグがあればだめですから、結局OSから全部セキュアにならないとだめなんでしょうね。
      親コメント
      • by G7 (3009) on 2002年05月04日 13時40分 (#89517)
        >JavaだってVMにバグが

        それは、手間の「数」の問題かと。

        ライブラリというものの存在意義(おおげさか)に関わる話ですが、
        その「一箇所を」直せば全部直るという側面があるわけですよね。
        JVM「さえ」直せばOKという面が。

        アプリ(?)側でのテストのやりなおしという代償は有りますが、
        テストの手間は、問題発生個所が分散していようがいまいが
        乱暴にいえば同じなわけですから、気にしても意味がない。

        また、

        >結局OSから全部セキュア

        たとえばVMがOSの不都合を「ラップ」するように作る、ということもできるわけですよね。
        #効率とか色々な面で馬鹿げた選択と言えてしまう場合「も」有るとはいえ。

        下層のOSから見ても、上層のアプリ(?)から見ても、ものごとがいったん「一点」に集約
        してしまうってのが、VMってものの強み(活かせるならば)ですよね。

        で、逆に、
        旧来(^^;のように、修正必要個所が分散していたら、どうなんでしょう?
        それって世間でよく言うような「リスク分散」に、なっているんでしょうか?

        プログラムはしばしば複数が協調して動く必要が有り、そのどれもが
        完全(ってのか)であることを求められるわけです(よね)から、
        修正個所を分散しても、ちっとも「リスク分散」したことに成らないと、思うのです。

        つまり、VMってものの有りようは、弱みよりも強みとして顕在化することのほうが「多い」のではないか?と、愚考するのですがどうでしょうか?
        親コメント
        • Re:えーと (スコア:2, すばらしい洞察)

          by take0m (4948) on 2002年05月04日 16時59分 (#89532) 日記
          そういう点で言うと、ActiveXはVMとおなじレイヤにあることになりますかね。
          親コメント
          • by tale (3290) on 2002年05月05日 2時20分 (#89665)

            でも実行を制限する機能を持ってないので、VM より実現できることが少ないですね。

            VM なら個々の動作ごとにやだって言えるタイミングがあるけど、ActiveX は一旦実行させてしまうと手を出せない。

            親コメント
    • by steve (8972) on 2002年05月08日 13時20分 (#90522)
      > バッファオーバーフローとかweb配信プログラムとか(のセキュリティ穴の話)を
      > 聞くたびに、やっぱりjavaのように、非nativeコードかつセキュリティモデルに囲われたモノでないと
      > ネットワーク(に限らないが)プログラムとしては事実上それっぽいトラブルを根絶できないのかな?とか
      > (弱気にも)思ってしまったりするんですが、どうなんでしょう?

      そんな事は無いと思う。
      Cだってセキュアな記述をしようとすれば出来る。>根絶できる
      それはjavaとかとは難易度が低いか高いかの差であって、javaだからボケたプログラムでOKって訳じゃないよね。

      javaで楽できるからって程度の低いプログラマでいい訳じゃないし、
      それがC(++)でプログラムするなって事にはならないでしょ?

      「なんでまだC(++)で書いてるの?」ってそりゃそっちの方が楽だから。
      javaの方が楽できればjavaで書くべし。
      streamのparseなんかをjavaとCで書き比べてみれば、
      程度にもよるけどCの方が半分くらいのコード量で済むんじゃないかな?
      # javaよりCの方が実行速度が速い訳ではなくって、
      # (Cで書くよりも何倍も)苦労すれば速度差はそれほどないです。

      要は労の少ない選択をして、
      適切な苦労のかけどころに、適切な苦労をする事でしょ:-)
      親コメント
      • by G7 (3009) on 2002年05月10日 2時25分 (#91326)
        >javaとかとは難易度が低いか高いかの差で

        その差を無視できないことを以って「(理学ではなく)工学的である」と言う、とか聞いたような記憶が有ります。
        つまりゲンジツ的であるかどうかという事。
        現にこれだけ事実として事故が起きているのですから、無視できないのでは?

        >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でセキュアなプログラムを(セキュアさが必要とされる場面で)書くことは、
        どれくらい労が少ないと言えるのでしょうか?(^^;;;;
        親コメント
  • by k3c (4386) on 2002年05月04日 15時49分 (#89526) ホームページ 日記
    ZDnetの記事 [com.com]中にMacromediaからの情報として書かれていますが、この脆弱性を持つFlashプレイヤーのバージョンは6.0r23だけであるとのことです。しかしやり方(とIEのセキュリティ設定)によってはそれ以前のバージョンから6.0r23へアップグレードさせることが可能なようですので、それ以前のバージョンでもやはり自発的なアップグレードがオススメです。
typodupeerror

私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike

読み込み中...