パスワードを忘れた? アカウント作成
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。

FlashのActiveXプラグインに脆弱性」記事へのコメント

  • 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でセキュアなプログラムを(セキュアさが必要とされる場面で)書くことは、
        どれくらい労が少ないと言えるのでしょうか?(^^;;;;
        親コメント

日本発のオープンソースソフトウェアは42件 -- ある官僚

処理中...