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

SunのJRE/JDK/SDKに深刻な脆弱性を発見 46

ストーリー by yoosee
お茶がこぼれるっ 部門より

Concerto曰く、"ITmediaITProによると、Sun Microsystems Inc.のJRE/JDK/SDKに深刻な脆弱性が発見されました。 この脆弱性を突かれると、リモートからファイルの読み取りと書き込み、アプリケーションの実行ができてしまうので、事実上システムを乗っ取られる事になります。

Secuniaの情報によれば、この脆弱性は「極めて深刻」なものであるとし、Sunからは既に脆弱性に対処したアップデートが出ているので、問題のあるバージョンを利用している方はアップデートをするように呼びかけています。なお、この脆弱性の影響を受けるのは

  • JRE 1.3.1_16以前/1.4.2_09以前/5.0 Update 5以前
  • Java SDK1.3.1_16以前/1.4.2_08以前
  • JDK5.0 Update 5以前
以上の Windows・Linux・Solaris版です。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • Sun Alert Notification #102171 [sun.com]より

    Note: It is recommended that affected versions be removed from your system. For more information, please see the installation notes on the respective java.sun.com download pages.

    実は旧バージョンを起動できるのかもしれません。 [srad.jp]

    • by Anonymous Coward on 2006年02月10日 22時15分 (#881467)
      > 実は旧バージョンを起動できるのかもしれません。 [srad.jp]
      その前ストーリーを読みつつJRE 5.0 Update 6をインストールしていたときの話です。
      JRE 5.0 Update 6を入れたら、過去の全てのバージョン用のレジストリが強制的にJRE 5.0 Update 6のプラグインを起動するよう書き換えられていました。
      # それはそれで特定バージョンが必要なイントラネット環境とかで困りそうだが
      では対策されたのかと思いきや、デュアルブートの別環境に入れてみたら今度はJRE 5.0 Update 6の分のレジストリしか更新されませんでした。よく分かりません。
      親コメント
  • by passer-by (13494) on 2006年02月10日 10時43分 (#881000) 日記
    $ java -version
    して出てくる番号をみても "Update xx" とやらに相当するのかどうか判断がつかなかったので、調べてみました。

    J2SE SDK/JRE Version String Naming Convention [sun.com]にバージョン番号表現の規約があります。
    今回の場合、JDK 5.0 系列なら「java version "1.5.0_05"」ないしは _05 がこれより小さいとダメという事のようです。
    末尾に -* がついていても (正式版より古い物なので) ダメ、と。

    "5.0" と "1.5.0" については Version 1.5.0 or 5.0? [sun.com]でしょうか。

  • JREのアップデート (スコア:2, おもしろおかしい)

    by Chaborin (5609) on 2006年02月10日 1時00分 (#880808)
    JREの1.4.2系を使っていると、タスクトレイにアイコンが出てきて5.0系にアップデートさせようとするんだけど、これ1.4.2系をわざわざ使ってるマシンでされると非常にうざいのだけど...
    通知はn日後にしても、また何日かしたら出てくるし。
    切ることはできないんでしょうか?
  • eclipsもやばいのかな (スコア:2, おもしろおかしい)

    by pinch (22469) on 2006年02月10日 1時17分 (#880816)
    Cross開発でeclipsを使っている人は、国内に多いんじゃないかな?
    チップメーカの開発環境がeclipsだったりすることも結構あるし。
    • by monaka (4489) on 2006年02月10日 9時26分 (#880939)
      Eclipseですか?

      ざっとリンク先を見る限り,提供された開発環境をふつーに使っている限りは,大きな問題はないと思います.

      ただし,Webブラウザとしても使っている場合はかなり微妙です.
      出所の判らないプラグインを追加した場合は…これは今回の脆弱性に限った話ではないですね.

      多くの環境は,Eclipse配下に,eclipse.exe だけが使うJREをいれています.単にJREをアップグレードしただけではEclipseが使っているJREのバージョンが上がらない可能性が高いです.そういう意味では,長期にわたって潜在的な爆弾を抱えることになる人は多いかもしれない.

      開発環境メーカからの発表を注意深く見守るか,この機会にEclipseそのもののお勉強をするか,どちらかの対策は必要かも.
      個人的には後者を勧めますけれども.
      --
      from もなか
      親コメント
    • Re:eclipsもやばいのかな (スコア:1, すばらしい洞察)

      by Anonymous Coward on 2006年02月10日 9時19分 (#880935)
      英単語のスペルをちゃんと覚えましょう。
      親コメント
  • 影響を受けるのは (スコア:2, すばらしい洞察)

    by 0-9a-zA-Z_.+!*'(),-\ (6182) on 2006年02月10日 12時19分 (#881065)
    > Java SDK1.3.1_16以前/1.4.2_08以前

    1.4.2_09以前じゃないの?
  • 僕は、Mac OS X と、FreeBSDで主にJavaを使って開発をしているんですが、Mac OS X版や、ports を使ってソースからコンパイルした、ネイティブFreeBSD版は大丈夫なのでしょうか?
    FreeBSD VuXML を見る限りでは、まだ Topic があがってきてないようですが・・・。
  • by Technical Type (3408) on 2006年02月10日 2時04分 (#880844)
    DoS 止まりだが、 Sun Java System Directory Server LDAP Denial of Service Vulnerability [frsirt.com] というのが見つかった。
    The FrSIRT is not aware of any official supplied patch for this issue.
    だそうだ。つまり、最新版でもダメな問題が既に発見されている。

    ホントーに Java って、脆弱性が見つかってから、また脆弱性が見つかるまでの間隔が短すぎるよね。12月も問題出したばっかりじゃないか。

    Java は、アンインストールして、二度とインストールしない方がセキュリティーは向上するな。

    • by MatsuTake (16700) on 2006年02月10日 2時37分 (#880864)

      DoS 止まりだが、 Sun Java System Directory Server LDAP Denial of Service Vulnerability というのが見つかった。

      Sun Java System Directory ServerとJREは別物です。

      ホントーに Java って、脆弱性が見つかってから、また脆弱性が見つかるまでの間隔が短すぎるよね。

      間隔はともかく、結構数が出ている印象はありますね。修正版が出てから脆弱性を公表するまでの期間が長いことも気になっているのですが、何か理由でもあるのでしょうか?

      親コメント
      • by Anonymous Coward on 2006年02月10日 5時44分 (#880890)
        >間隔はともかく、結構数が出ている印象はありますね。修正版が出てから脆弱性を公表するまでの期間が長いことも気になっているのですが、何か理由でもあるのでしょうか?

        間隔が短いと、発表された脆弱性を持つ環境が
        たくさん残った状態でより多くの攻撃者に
        セキュリティホールを知らせてしまうからでは
        ないでしょうか。
        # どうあがいても知る人は知ってしまうので
        # そういうひと以外にわざわざ知らせない、という意味

        セキュリティパッチが出てないのに
        公表されると怖いですよ。さすがに。
        AppleのJVMは、SUNより遅れるのでこういう配慮は
        嬉しいです。
        親コメント
        • 間隔が短いと、発表された脆弱性を持つ環境がたくさん残った状態でより多くの攻撃者にセキュリティホールを知らせてしまうからではないでしょうか。

          脆弱性が公表されなければ多くの利用者はアップデートせず、脆弱性を持つ環境がたくさん残った状態のままなのでは?

          また、パッチをリバースエンジニアリングしてExploitコードが作られたり [impress.co.jp]もしているようなので、脆弱性の発表前に修正版を出すこと自体がより多くの攻撃者にセキュリティホールを知らせてしまう原因にもなりかねません。

          AppleのJVMは、SUNより遅れるのでこういう配慮は嬉しいです。

          それは企業間で連絡を取り合うなり、CERT/CC [cert.org]とかに協力してもらうなりして調整すれば良いだけの話です。

          親コメント
    • by moriyoshi (15909) on 2006年02月10日 19時06分 (#881347)
      元コメントは多少言いすぎかと思いますが、私のタレこんだバッファオーバフローの問題 [sun.com]も 1.5.0_06 では直っているということで放置されたまま。他のささいな脆弱性とあわせてexploitられることで深刻な状況を生み出しうるということに気が回らないんでしょうかね。
      親コメント
  • 昔はMS製のJavaVM(今のJ#)が危険だとか何とかで
    騒がれた時期があったものですが、SunのJavaVMも
    セキュリティが安全では無くなってきたのですねえ。

    ところでJavaは未だにVC++6で開発していると聞いたことが
    あるのですが、VC++6よりIntelコンパイラで開発して
    ほしいと思うのはたぶん私だけでしょうか。
    • by Anonymous Coward on 2006年02月10日 9時28分 (#880941)
      JavaはMS JavaVMが配布される前から危険でしたよ。
      脆弱性を回避するために仕様変更が繰り返されているので
      昔に書いたプログラムソースとの互換性も保たれてはいないです。

      Write once, Run anywhere という宣伝文句の実現も絶望的ですし、
      Javaで書かれたソフトをいくつか利用しているユーザの立場から言うと
      ソフトによって動作するJREのバージョンが違うために、それぞれの
      ソフト専用でマシンを用意する必要があって不便です。

      脆弱性を修正するためにバージョンアップをしたら
      「そのバージョンでは動かない」といって強制終了されることもあります。
      結果的に脆弱性を抱えたまま使い続ける羽目になります。

      Javaの採用はユーザにとって良いことなのではなく、開発者(社)にとって
      開発しやすい、移植しやすいという理由だけなんじゃないかと思います。

      Windowsの脆弱性修正パッチを当てると、使用中のソフトが動かなくなる
      可能性があるから容易には実施できないと聞きますが、Javaの場合も
      似たようなものです。
      いや、もっと酷いか。
      親コメント
      • by Another_View (29838) on 2006年02月10日 16時43分 (#881258) ホームページ 日記
        脆弱性どころか、仕様全般にわたって変更しすぎだ。
        初期のころのJava解説本のサンプルコードはほとんど全てアウト。

        なんでこんなもんを使いたがるのか知りたいもんだ。
        親コメント
        • > 脆弱性どころか、仕様全般にわたって変更しすぎだ。
          > 初期のころのJava解説本のサンプルコードはほとんど全てアウト。

          具体的にはどんなコードがアウトになるのですか?
          • http://java.sun.com/docs/books/jls/clarify.html
            • ぱっと見たところ JLS1st から JLS2nd への変更ですね。曖昧である部分を明確化していたり仕様の間違いを訂正しているものが多く、ほとんどの修正はコンパイラはともかく、コードには影響を与えないように見えます。
              • JDK 1.0のAppletViewerで動かせるアプレットを公開しています。数年間再コンパイルすらしていませんが、最新のJRE 5.0 Update 6でも何の問題もなく動いています。
                何でこんなFUDを流す人たちがいるのか逆に知りたいですね。具体例を聞いてもぜんぜん出てこないし。
              • by Anonymous Coward on 2006年02月11日 1時02分 (#881561)
                >JDK 1.0のAppletViewerで動かせるアプレットを公開しています。数年間再コンパイルすらしていませんが、最新のJRE 5.0 Update 6でも何の問題もなく動いています。

                それは、本当に何の問題もないのか?

                危ない脆弱性を抱えたアプレットか、もしくは極単純な機能しかない
                役に立たないゴミアプレットなのではないか?
                君の公開しているアプレットがたまたま動くだけじゃないのか?
                君のアプレットがたまたま動いたからといって、他のJavaソフトも
                同じように動くとなぜ言える?

                バイナリレベルの下位互換性はそこそこあるが、互換性のない場合もある。
                ソースレベルの下位互換性は保証されておらず、非推奨APIが使われている
                ソースをコンパイルできるように一応は残っているが、バージョンが
                大きく違うとそれも怪しい。
                非推奨APIを使い続けているアプリケーションがまともなものなのかは知らん。
                君のソースコードは最新の開発環境で再コンパイルできるか?

                FUDではなく、実際の話として動作しないソフトはある。
                開発者が、将来に渡って変わっていくJavaの仕様に対して自信が持てず、
                仕様が変わったがために誤動作し、損害が発生するのを恐れて
                実行環境のバージョンをチェックして新しいバージョンでは動かないように
                しているソフトもある。
                重要なデータを処理するようなソフトであれば尚更である。
                親コメント
              • だから具体例を教えてください。
              • 具体例具体例ってうるさい奴だな。
                少しは自分で調べることもしろ。馬鹿が。

                http://java.sun.com/j2se/1.5.0/ja/compatibility.html

                ここでもよく読め。
                読まずによく分かったふりするなよ。
              • 親コメントのACさんが、何の具体例として上記のリンクをあげたのかは知りませんが、少なくとも #880941さん [srad.jp]がおっしゃるような脆弱性を回避するための仕様変更の例とは言い難いものが多いですね。例えば

                7. 仮想マシン - これまで、クラスリテラル (Foo.class など) を評価するとクラスが初期化されました。5.0 では初期化されません。前の動作に依存するコードは書き直す必要があります。

                なんかは、

                詳細についてはJava 言語仕様のクラスおよびインタフェースの初期化 (節 12.4) を参照してください。言語仕様は変わっていませんの

              • by Anonymous Coward on 2006年02月11日 22時18分 (#881844)
                あなたが結局具体例を挙げられないのはよくわかりました。
                あなたのいう動かなくなるソフトも何も、あなたの話には全然信用性がないのですね。
                だからあなたはFUDと呼ばれているのですよ?
                親コメント
              • > あなたのいう動かなくなるソフトも何も、あなたの話には全然信用性がないのですね。
                自分は何一つ証拠を見せないくせに人には悪魔の証明を求めるくらいですからねえ。信用しろという方が無理ですよね。
      • by Anonymous Coward on 2006年02月10日 10時26分 (#880982)
        >脆弱性を回避するために仕様変更が繰り返されているので

        この部分の具体例を教えてください。
        親コメント
    • by Anonymous Coward on 2006年02月10日 2時19分 (#880852)
      いいえ。元々危険でした。仕様そのものの脆弱性と、実装の脆弱性両方ともにあります。
      MS JVMはMSだから、ということでセンセーショナルに叩かれていた面も否定できません。
      しかもSun自身が脆弱性情報の隠蔽傾向にあり、ひっそりとリビジョンを上げて知らんぷり、ということも過去行われています。
      親コメント
      • さすがに最近は知らんぷり、ではありません。一応新版が出た際に、リリースノートに修正バグ一覧が出ますし、問題の程度も BTS 繰ればある程度分かります。但し、新版のリリースはひっそりと出ますけど。

        #と言うわけで、1.4.2_08 のバグがなんで今頃ネタになるのが全然分からない。1.4.2_09 でも致命的なバグはあるのに。

        親コメント
      • by Anonymous Coward
        テキトーなこと言うなよ。

        > 仕様そのものの脆弱性と、

        使用そのものの脆弱性って何のこと?
    • ところでJavaは未だにVC++6で開発していると聞いたことがあるのですが、

      それは本当です。 Sun JavaSE 6 より前は VC6 + SP3 でした。
      でも Linux はもっと酷くてビルドに RedHatLinux 6.x が必要です。 GCC 3.x 系でビルドするには、かなりパッチングが必要です。
      VC++6よりIntelコンパイラで開発してほしいと思うのはたぶん私だけでしょうか。
      Intel C/C++ Compiler にはバグが多いのでお薦めし難いです。
      実際に ICC でコンパイルしよとすると、最適化を上げていると compiler internal error が出てダメ。
      最適化を切って(-O0)でソースをあちこち修正すればビルドはできますが速くはなりません。JIT コンパイルは速くなっても、翻訳されたコードの速度は変わらないから。
  • 発見者、発見時期、問題のあるバージョンをみるにこの記事の脆弱性 [srad.jp]と同一のように見えます。
    --
    コンタミは発見の母
    • by Technical Type (3408) on 2006年02月11日 1時15分 (#881566)
      > 発見者、発見時期、問題のあるバージョンをみるにこの記事の脆弱性 [srad.jp]と同一のように見えます。

      ハズレと違います?

      • 発見者は両方Adam Gowdiak氏
      • 発見時期は
        • 前回は 2005-11-28
        • 今回は 2006-02-07
      • 問題のあるバージョンは、5系を例にとると
        • 前回は JDK and JRE 5.0 Update 3 and earlier
        • 今回は JDK and JRE 5.0 Update 5 and earlier
      とありますし、CERT のVU#759996 [cert.org]には
      Note these issues are different from the one reported in VU#974188 [cert.org].
      とあります。 ま・・・例えばバージョン5系なら、「JDK and JRE 5.0 Update 6 なら両方の脆弱性ともセーフだから一緒」みたいにラフな考え方もできますがね。
      親コメント
      • 勘違いしていました。

        5.0 系はマイナーバージョンアップで修正と機能拡張が同時に行われるので安定している 1.3.1 系と 1.4.2 系を見てみると、今回の脆弱性への対応は java.lang.reflect.Proxy クラスと sun.misc.ProxyGenerator クラスに入っているものですね。

        前回の脆弱性への対応はどこに入っているのか分かり辛いのですが、java.beans.Introspector やその他のライブラリで reflection API を使っているところにパラパラと修正が入っているのが、対応っぽい気がします。

        # 今回の脆弱性って使えるのかなぁ。
        # Java に -Xverify:none とか指定していない限り verifier が弾いてしまうような気がする。
        --
        コンタミは発見の母
        親コメント
  • IBMのJRE1.4.2は (スコア:0, 興味深い)

    by Anonymous Coward on 2006年02月10日 7時57分 (#880911)
    問題ないってことでいいですか?
  • by Anonymous Coward on 2006年02月10日 10時47分 (#881002)
    アプレット関連の脆弱性のようですが、これはTomcatを動かすためだけにjavaをインストールしているサーバ環境等では影響がないと考えてOK?

    #おそらく大丈夫と踏んでいるが臆病者なのでAC
  • by Anonymous Coward on 2006年02月12日 7時06分 (#881952)
    セキュリティホールが浜の真砂の如く尽きない感もあるSunのJRE/JDK/SDKですが
typodupeerror

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

読み込み中...