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

Mozilla Firefox1.0.3に最高レベルの脆弱性」記事へのコメント

  • 複数の脆弱性の合わせ技であるわけだけど、よく見ると最後の部分である「batch/exe 等攻撃コードが実行」は脆弱性ではなく、Firefoxのデフォルトの機能ってことなの?
    何で、JavaScriptからbatch/exeの実行ができるような仕様になってるんだ?
    もしもこんな仕様でなければ、セキュリティレベルも高ぐらいで済んだんじゃないかと思うんだけどなあ。
    • JavaScriptは別に通常のサイト閲覧時に読み込まれたHTML上で実行される
      だけの用途で使われる言語ではないですよ。

      今回の場合は、問題のコードを含む拡張機能等をエンドユーザが任意に
      インストールし有効にした際、想定しないプログラムが実行される
      可能性がある、という事だと思います。
      • 別に
        JavaScriptは通常のサイト閲覧時に読み込まれたHTML上で実行されるだけ
        とかは言ってないし、そこを問題にしているのではない。
        IFRAME→JavaScript→XPI→XPI内のJavaScript→batch/exeという流れでやられちゃうわけだよね?
        最終的にbatch/exeを起動できる仕様がダメなんじゃないのかと言ってるんだが。

        Exploit Codeで言うと、
        \\\\\\\\nPAUSE\\\\\\\';outputStream.write(output,output.length);outputStream.close();file.launch();
        の最後の部分である「launch();」こんなのができるのが問題なのではないかと。
        # batch/exeを起動しているのはこのlaunch()だと思うんだけど、外してたらゴメン。
        HTMLから始まってbatch/exeに到達できるルートがあるのはダメだと思う。
        親コメント
        • by mal (3063) <mal.blue342NO@SPAMgmail.com> on 2005年05月10日 11時06分 (#732894)
          > HTMLから始まってbatch/exeに到達できるルートがあるのはダメだと思う。

          Exploit Code で言うと、
          netscape.security.PrivilegeManager.enablePrivilege(\\\\\\\'
          UniversalXPConnect\\\\\\\')

          が問題になるんでしょう。個人的にはもうこれいらないと思うんですが。

          ただし、PrivilegeManager の正常動作の場合は、普通は警告が出まくるようになっています(cancel 可能)。Web 上だと about: config で signed.applets.codebase_principal_support を true にしなければ使うことさえできません。true にして対象の javascript を signed script にしても警告が出ます。ローカルファイル(file:) だと ON にしなくてもつかえますが、やはり警告が出ます。

          今回の脆弱性の2番目のもの、
          リモートからのソフトウェアインストール機構(アドインや拡張など)に使われるJavaScript関数でのURL引数の検証漏れに起因する、任意JavaScriptコードの実行権限の奪取が可能となる脆弱性となっている。

          これが、PrivilegeManager からの警告をスルーしてしまう大穴です。
          親コメント
          • なるほど、参考になりましたです。
            やはり、技術的に分かっている人の解説はいい!
            732879のACにも感謝。

            # しかし、記事の投稿から丸一日経って初めてExploit Codeの技術的な解説がなされるっていうのは、なんか寂しいよなぁ。
            親コメント
        • by esumi (15966) on 2005年05月10日 10時09分 (#732869)
          ご指摘の件についてはこちらの早とちりでした。お詫びいたします。

          最終的にbatch/exeを起動できる仕様がダメなんじゃないのか、とのこと
          ですが、XPI側の段階で、その機能をインストールするにはユーザーの意志決定が
          必要なのではないでしょうか。信頼の置けないサイトの提供する機能は
          インストールしない設定にしておけば防げるというような記事だったと思うのですが

          某OSを提供している大企業のどなたかも言ってましたけど、
          ユーザーが自分の意志で実行したりインストールしたりするのを防ぐ決定的な手段は
          私は無いと思います。
          信用の置けないサイトが提供する機能はインストールしない設定にしておくというの
          は、信用の置けないサイトが配賦しているフリーソフトウエアをダウンロードし
          インストールしないのと同じ事であり、ユーザ側の方で常に最低限、
          心がけるべき事なのではないでしょうか。

          個人的には悪意のあるコードが含まれるプログラムの実行前に、
          該当プログラムに対してユーザー側に明確な実行への意志決定が介在する
          のであるなら、結果への責任はそのユーザーが負うのが筋なのではないかと
          思っています。その脆弱性の為に完全にオート
          で(ユーザーの意志決定の介在余地無く)実行される類で無い限りは。

          もちろん、今回は脆弱性をついたコードという事なので、それを素早く埋める
          努力をするのは提供側の義務でもありますけど。
          親コメント
        • by Anonymous Coward on 2005年05月10日 10時37分 (#732879)
          > IFRAME→JavaScript→XPI→XPI内のJavascript...
          > という流れでやられちゃうわけだよね?

          違います。XPI内のjavascriptは何の関係もありません。

          > launch()
          そうです。

          しかしながら、仮にlaunchというメソッドがscriptableでなくなったとしても、依然として実行ファイルを実行する方法はありますし、他のセキュリティリスクが回避できるわけではありません。例えば、既存の実行ファイルとすげ替えることもできるので、スクリプト上からの実行を阻んだとしても、何の解決にもなっていないのです。(そのファイルがOSの起動ごとに実行されるシェルや実行ファイルである場合を想像してみてください。)

          webからXPCOMを使える状態にされた時点でこの勝負は「負け」です。逆に言うと、launch()メソッドの有無による安全性への影響はゼロです。
          親コメント
          • >webからXPCOMを使える状態にされた時点でこの勝負は「負け」

            参考になる +10

            なるほど。しかしオプションの「Webサイトによるソフトウェアのインストールを許可する」で
            許可リストに加えられたサイトは、正当な権利としてそれらができてしま
            • > 「Webサイトによるソフトウェアのインストールを許可する」で
              許可リストに加えられたサイトは、正当な権利としてそれらができてしまうんですよね?

              違います。前にも書きましたが、PrivilegeManager の存在が問題です。
              「Webサイトによるソフトウェアのインストールを許可する」と可能な XPInstall に PrivilegeManager の警告を無視してしまう脆弱性があったということで、XPInstall そのものには「実行中のユーザ権限をまるごと与える」ことはできません。

              #ファイルの作成・削除・移動はできるけど...これもやばいんだよなぁ。
              親コメント

※ただしPHPを除く -- あるAdmin

処理中...