パスワードを忘れた？ アカウント作成
Close
4758 story

各社のJava VMに砂場の枠が外れる脆弱性 15

ストーリー by Oliver
砂場に落し穴 部門より

jbeef曰く、"11月25日にBUGTRAQに流れた記事によると、 ポーランドのグループが、Netscape、Microsoft、SunのそれぞれのJava VMに、 bytecode verifierのチェック漏れやJITコンパイラのバグなどが原因の セキュリティホールを発見したという。 Netscape 4.0～4.8（Windows, Unix版）と Internet Explorer 4.0～6.0では、 sandboxセキュリティ制約が崩れ、その結果、ローカルファイルの読み出しや、任意コマンドのローカル実行などの脅威がもたらされる。 Netscape 4.xでは、JDBC関連のシステムクラスの実装ミスもあり、合わせ技によって、任意のネイティブコードの実行もできてしまうという。 SunのVMについては、発見者の報告では、JDK 1.1～1.4においてbytecode verifierのチェック漏れが見つかったが、Netscape 6およびappletviewerではexploitに成功しなかったという。しかし、Sunから12月12日付けでSun Alert ID: 49304「Java VM Allows Constructors not to Call Other Constructors」が出ている。発見者は9月にSun、Microsoft、Netscapeそれぞれにこれを伝えたが、MicrosoftとNetscapeからはなんら返事がなかったという。"

"bytecode verifierのチェック漏れはJavaが登場した当初からときどき発見されては修正されてきた（最近では2002年3月発表のものが最後だった）が、具体的にどんな手順で攻撃されるかはほとんど公表されないできた。そのため、高度な技術を持つものにしか攻撃できないとされ、現実的な脅威は低めに見積もられることがあった。しかし、 今回の発見者グループのサイトでは、今回のものと、過去に話題となったが公表されなかったものについても、具体的な方法を解説している。 こうした言語システムの設計、実装に携わっている者にとっては、 現実を知る上で参考になる資料となろう。 JITコンパイラのバグは、Netscape 4に採用されていたSymantec製のもの。 ある並びのbytecode列が誤ったコードに変換されるため、 指定した番地にジャンプさせることができてしまうという。

解決方法は、Sun Alert ID: 49304によると、 JREを最新版（1.4.1_01以降、1.4.0_03以降、1.3.1_06以降、1.2.2_014以降）へアップグレードせよとのこと。1.1.x 系列の対策版はないらしい。 Netscape 4.xとInternet Explorerについては今のところ Javaをオフにして回避するしかない。
なお、日本のサンマイクロシステムズからは1か月が経過した現在も告知が出ていない。 日本HPからは既に日本語訳が出ているので日本サンはそれを参考にしたらどうか。"

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

各社のJava VMに砂場の枠が外れる脆弱性 More

  • 私も他人事ではないので 発見者グループ [lsd-pl.net]の解説記事のうち、 PowerPoint のプレゼン資料を読んでみた。
    このグループはよく調べていると思うけど、 現実の環境でこの資料にある穴をついてセキュリティを 破るのは難しいと思う。 少なくとも私にはすぐには考えつかない。 ただ PDFの full paper の方を 読みきると印象が変わるかもしれない。

    あと、PowerPoint 資料中に
    "There seems to be not sufficient public discussion about weaknesses of JAVA (why?)"
    という文があったが、 いちおう SUN の Java 関連製品に関しては その名も高き BugParade [sun.com] (閲覧には登録が必要)というのがある。
    ここにはセキュリティ関係のものも含めて、 しこたまバグ報告が登録されている。 ここを読んでいると新しいバグ報告がきても驚かなくなる･･･

    ＃ bug parade なんていうネーミングもどうかと思うのだが、、、
    --
    コンタミは発見の母

    • Re:Bug Parade (スコア:4, 参考になる)

      by jbeef (1278) on 2003年01月19日 23時06分 (#238723) 日記
      実の環境でこの資料にある穴をついてセキュリティを破るのは難しいと思う。
      発見者のメール [securepoint.com] には、
      Along with the paper, we also plan to release proof of concept codes for all of the vulnerabilites that are discussed in it. But this will be done in about 1 week time from now.
      とあるので、実際に破ることに成功したデモコードを持っているのではないでしょうか。（結局出さなかったみたいですが、やはりデモを出すことが信じない人を減らすのでしょうね。）

      「実の環境で」といっても、Javaの上で起きることは環境によらず再現性があるのですから、type confusion攻撃が成功して、クラスローダ周りのclass spoofingができれば、あとはクラスローダに関連付けられたPermission情報をすり替えて、システムクラスと同じ何でもできる権限を得るというのはできそうに思えます。（というか、スライドにズバリその方法が書かれているような。） SunのVMでそれ（クラスローダのclass spoofingによる攻撃）ができなかったのがloadClass()メソッドがfinalだったためとも書かれていますよね。

      という文があったが、いちおう SUN の Java 関連製品に関してはその名も高き BugParadeというのがある。
      セキュリティ関連のバグもBugParadeにありますが、脆弱性のことは公開していないと思いますよ。セキュリティ機能のバグと、セキュリティ脆弱性とは別ですね。

      ちなみに、過去に、bytecode verifierの検証漏れが引き起こす脆弱性の話題を扱ったものとしては、以下の本があります。（Webでも読めます。太っ腹。）

      シェア
      親コメント
      • まだ、full paper も G. McGraw の Web も読んでいない状態でのレスです。ご勘弁を。
        「実の環境で」といっても、Javaの上で起きることは環境によらず再現性があるのですから、 type confusion攻撃が成功して、クラスローダ周りのclass spoofingができれば、 あとはクラスローダに関連付けられたPermission情報をすり替えて、 システムクラスと同じ何でもできる権限を得るというのはできそうに思えます。 （というか、スライドにズバリその方法が書かれているような。） SunのVMでそれ（クラスローダのclass spoofingによる攻撃）が できなかったのがloadClass()メソッドがfinalだったためとも書かれていますよね。
        ぶっちゃけた話、 私が「現実の環境」と断わったのは SUN JDK 1.3.x / 1.4.x を想定してのことです。
        というのも JDK 1.2 系以前の JavaVM と較べて、 1.3.x 系の JavaVM は速度が圧倒的です。 Java を使っている人は SUN or IBM or BEA の J2SE 1.3 or 1.4 の JavaVM をダウンロードして載せているだろうと信じています。
        ＃ Java 屋の妄想家もしれませんが(涙)。

        今回問題となっている bytecode verifer の漏れなのですが、 スライドの P.71 以降に解説があります。
        この解説を読めば Symantec JIT compiler と MSIE の脆弱性は分かるのですが、 SUN の JDK 1.3 でどうやって type confusion を起こすのか、 1番肝になる部分が書いてないように読めます。 さすがに古いバグパターンがそのまま適用可能ということはないですよね。

        あと、スライド中の 「SUN の VM では loadClass() メソッドが final にマークされていた」 が何を意味するのか悩んでいるのですが、誰か分かる人いますか？


        セキュリティ関連のバグもBugParadeにありますが、脆弱性のことは公開していないと思いますよ。 セキュリティ機能のバグと、セキュリティ脆弱性とは別ですね。
        セキュリティや bytecode verifer のバグが分かれば、 脆弱性を類推することは容易だと思いますが、、、、、、 という分けにはいかないでしょうね。

        ただ現行の JavaVM の脆弱性は、 仕様自体にセキュリティホールがあるというわけではなくて、 実装が仕様から外れた部分で出ていますよね。
        ですから、 BugParade 的な手法で丹念にバグを潰していくことがセキュリティ確保の近道だと思いますがどうでしょう？
        --
        コンタミは発見の母
        シェア
        親コメント

    • Re:Bug Parade (スコア:1)

      by happy (8310) on 2003年01月25日 16時41分 (#243241)
      JVM の本とか読んで、Java アセンブラも面白そうだと思ったんですが暇が・・・

      アセンブラ自体は前からありますし、携帯向けJavaでガリガリ触る人も増えてきて、悪用できるレベルの人は意外と居るのかもしれない、って気がしないでもない。
      シェア
      親コメント
      • > JVM の本とか読んで、Java アセンブラも面白そうだと思ったんですが暇が・・・
        >
        > アセンブラ自体は前からありますし、携帯向けJavaでガリガリ触る人も増えてきて、
        > 悪用できるレベルの人は意外と居るのかもしれない、って気がしないでもない。

        JavaVM を学ぶのはいのですが、
        バイトコード自体を勉強するのはお薦めしません。

        2つ理由があります。

        1つは Java バイトコードという技術は 面白くなくもないのですが、
        スタックマシンという実世界にはあまりない仮想マシン上の
        アセンブラ言語なので、これを学んでも応用力がありません。

        携帯用 Java のアプリを書きたいとか、Ruby から Java バイト
        コードに翻訳するコンパイラが書きたいとか、 なんか明確な目的
        がない場合にはお薦めしません。

        むしろガーベージコレクションの技術とかを学ぶ方が面白いですし、
        役に立ちます。

        もう1つは Java バイトコードを直接書くことによるメリットがほとんどない点です。

        バイトコードのポテンシャルは、Java 言語のそれとあまり変わりません。
        というのも、.NET の MSIL と違って、Java バイトコードは Java 言語からの変換のみを考慮して作成されたものなので裏命令みたいのはないですし、
        バイトコードの制約から命令の並び方も決まってくるのでトリッキーな書き方で速度を稼ぐと言うようなことがほとんどできないのです。
        C 言語のプログラムの一部をアセンブラで高速化というようなのりとは全然違います。

        携帯用の Java の世界では、数バイトを削るために目的バイトコードを直接つかってガリガリ書くことがあるかもしれませんが、Java2 SE/EE の世界では、少々 バイトコードを最適化しても dynamic compiler が最適化すると同じになってしまいます。
        ＃ 次の Java2 ME には JIT コンパイラも入ります。
        --
        コンタミは発見の母
        シェア
        親コメント
  • Windowsの場合、Netscape 4.x も IEも、Java 2 Runtime を最新にした上で、Java Plug-in を <applet> タグ、<object>タグで使う設定にすればいいのではないのでせぅか?
    使わないのがいいけど。
    --
    okome

  • 120日で問題は解決です。 (スコア:0)

    by Anonymous Coward on 2003年01月20日 7時39分 (#238914)
    120日後にはみんなJRE1.4.1_01以降が載る事になる [srad.jp]んじゃなかったっけ？

  • 空目 (スコア:0)

    by Anonymous Coward on 2003年01月20日 10時20分 (#238976)
    ボーランドのグループって読んじゃったの、オレだけ?

  • 各社のJavaVMってことは (スコア:0)

    by Anonymous Coward on 2003年01月20日 10時47分 (#238993)
    もしかしたらケータイに搭載されたJavaVMにもあるんだろうか？
    …あったらアップデートしてもらえるんかな？
    • あるかもしれないけどJVMでは対応しきれないでしょう。

      だって携帯で動くクラスは既にクラスベリファイされたものだから
      クラスベリファイアにバグがあった場合は、
      全てのクラスを再ベリファイしないとだめですから。
typodupeerror

ソースを見ろ -- ある4桁UID