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

<= 2.4.22にローカルセキュリティホール 39

ストーリー by Oliver
開発者は一瞬も気を抜けない 部門より

masayang 曰く、 "Debianのセキュリティアナウンスより。カーネル2.4.22/2.6.0-test5までのバージョンには、ローカルで実行されるプログラムがカーネル内の全メモリ空間にアクセスできてしまうバグがあったようです。Debianでは2.4.18-14で修正されている、とのこと。"

不正侵入されたDebianサーバのイメージを解剖調査した結果、暗号化された攻撃ツールを発見。さらなる解析で復号化に成功し、Red HatとSuSEのカーネルチームとの協力でカーネルを攻撃するツールであることが判明した。悪用されたバグはbrk(2)システムコールに存在したInteger Overflowで、新規にマップされるアドレス領域の終端が始まりの前でないかがチェックされていなかったものだ。バグ自体は9月に発見・修正されたが、これまでは悪用が可能とは思われていなかった。興味を持った人は2.4.23および2.6.0-test6以降でmm/mmap.c内do_brk()の冒頭でEINVALが返されるところを見てみよう。

このバグを悪用するコードは現時点では一般に流通していなくとも、実存していて、なおかつ悪意を持って使われているので、古いカーネルを使っている人は早めにアップグレードするか問題の所に2行パッチを当てるべきだろう。

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 今回の問題の要 (スコア:4, 参考になる)

    by Anonymous Coward on 2003年12月02日 11時00分 (#445843)
    今回の件から学ぶ(すでに言われ尽くしたことだろうけど)ことは
    1. ローカルなセキュリティホールでも他の技(今回はwiretap)と組み合わせることでリモートから攻撃可能
    2. 公開前のセキュリティホールが悪用される(ゼロデイアタック)
    3. tripwire などのツールがあったため、検出が速かった
    4. 攻撃コード自体を暗号化し、解析に時間をかけさせている
    といったあたりでしょうか?
    • by kiyotan (3912) on 2003年12月02日 11時53分 (#445894) 日記

      ローカルなセキュリティホールでも他の技(今回はwiretap)と組み合わせることでリモートから攻撃可能


      この情報ってどこにあるんですか?
      前回のストーリーと今回のストーリーのリンク先には
      見当たらなかったような気がしたんですが...
      --
      Kiyotan
      親コメント
    • by Anonymous Coward
      5. オープンソースは多くの人がチェックするので脆弱性が発見されやすいが、
       発見するのは必ずしも善意の人間とは限らない
      • by Anonymous Coward
        5' (中略)
        発見されたからといってそのリスクが確実に評価されるとも限らない
        # 今回はバグの影響を低く見てたのが原因だよね?
      • by Anonymous Coward
        6. どのOSが安全だ、とかいう論争はもう飽きた
        • by greentea (17971) on 2003年12月03日 2時16分 (#446523) 日記
          7. もしこのセキュリティホールを出したのがWindowsだったら、激しいWindows叩きが始まっていた

          #クラッキングされたとはいえメモリ全部は痛すぎ。
          #Linux使いたいのに使い方分からない俺も痛いが。
          --
          1を聞いて0を知れ!
          親コメント
  • by null (224) on 2003年12月02日 13時34分 (#445984)
    Redhat からも redhat 7.x, 8, 9 用の errata がでました。
     
    http://rhn.redhat.com/errata/RHSA-2003-392.html [redhat.com]
    • by Anonymous Coward

      発見されてから約3カ月間の間、この脆弱性は公表されていなかった。

      全然関係がない話題だけど、「クローズドなプロダクトはセキュリティホールを秘密にする傾向にあるので、長期間ユーザを危険に晒す可能性がある」というようなFUDを聞いたことがある。


      #独り言なのでAC

  • by Henrich (121) on 2003年12月02日 10時05分 (#445781)
    何故か 2.4.23-pre1の頃から
    Uncompressing Linux... Ok, booting the kernel.
    でストップするんですよ、うちのサーバ。なんでだろ~?
    (同じ症状の人いません?)

    今回の対策はpatch当てだけで済ませられるけど、今後はどうしようかなー
    #local user全然いないので大丈夫っていえば大丈夫なんだけど。
    • by hsgw (14585) on 2003年12月02日 10時54分 (#445838)
      config でカーネルの機能を削りすぎたんでしょうね。
      (1) LILO なり GRUB なりが圧縮されたカーネルを見つけて
      (2) メモリ上にロードし、カーネルの頭に制御を移し
      (3) カーネルは自己の解凍ルーチンを実行し、0x100000に飛ぶ
      (4) カーネル本体がようやくバナーとかを表示してハードウェアの初期化
      という流れになっているので、バナーさえ出ていないということは (3)と(4)の間で止まっているのでしょう。
      ということで、具体的なデバイスドライバの指定間違いというよりは プロセッサの指定ミスやカーネルの基本的な部分(例えば仮想コンソールとか)での抜けだろうと思います。
      不要だと判断して削った項目を少しずつ増やしながら様子を見るのがよいかと思います。
      親コメント
    • lilo の設定を変えて、コンソールにメッセージを出力させようと
      したときに、同じような症状(?)というか現象はありましたね。

      当然、コンソールにはつらつらとメッセージが出ていましたが、
      最初はビビリました。。。
      • by Henrich (121) on 2003年12月02日 10時37分 (#445815)
        うーん、2.4.22の頃からconfigほぼ変わってないんですよ。grubも同様に変化なし。
        なので、そこらが変わったのでなければ当てはまらないかな、とも思うのですが。

        とりあえず、もう一度チェックしてみます。
        コメントありがとう。
        親コメント
    • オープンソースなんだから。
      たまにはprintfデバックしてみるとか。

      カーネルソースは昔いじっただけなのでAC
      • カーネルなので printk という無粋な突っ込みは置いておいて, 闇雲に print(f|k) するぐらいなら、Bochs のデバッガ機能を 使って追いかけたほうがよっぽど効率的です。
        ちなみに、今回は Uncompress まで動いている感じですので、 printk でもよいですが、そもそもプロテクトモードに移行できてなかったりした場合には、printk さえも使えなかったりします。
    • > Uncompressing Linux... Ok, booting the kernel.
      > でストップするんですよ、うちのサーバ。なんでだろ~?

      私も発生しました。
      原因は分かりませんが、カーネルに ram=○M オプションを付ければ回避できました。
      • 先ほどのACです。

        mem=○M
        ram=○M

        これの違いの分かる人居ますか?
        自分では前者を指定したかったのですが、頭に思い浮かんで実際に指定のが後者でした。
        ram の方は RAMDISK の容量かと思いましたが、dmesg を見ると指定したサイズは確保されていません。う~ん。
        どこか参考になるホームページはないですかね?
        • "ram="なんてコマンドラインパラメータはありません [linux.or.jp]よ?
          何かの勘違いなのでは。
          付けたのは"mem="だったか、偶然ブート周りのバグを回避出来ただけなんでは。
          --
          # rm -rf ./.
          親コメント
          • パラメータのページを紹介して頂きありがとうございます。

            > $ dmesg | grep command
            > Kernel command line: ro root=/dev/hda5 ram=48M

            なので、ram= です。ram=4M でもOKでした。
            #存在しないパラメータならなんでもOK?
            ちなみに mem= では起動に失敗しました。

            > 偶然ブート周りのバグを回避出来ただけなんでは。

            とりあえず、これで納得しておきます。
        • by pantora (11989) on 2003年12月02日 17時32分 (#446148)
          > ram=○M

          RAMディスクのデフォルトサイズを指定する
          昔のオプション「ramdisk=」の間違いじゃない?
          今は「ramdisk_size=」というオプションになっております。
          --
          PCにECC Registeredメモリの利用を推奨します。
          親コメント
  • Linux系のプロジェクトの公開サーバで,そのカーネルを使っているサーバが Debian のサーバだっただけで,RedHat のサーバも攻撃の対象となりえたと.

    Linux 全然知らんのでアレなんですが,何で Debian を狙ったんだろう?
    他のプロジェクトのサーバでも,同カーネル使ってる所はあったんでは? と思うのですが…
    Linux の詳しい人教えてください.
    --
    ------------------------
    いつかきちんと仕上げよう
  • by Anonymous Coward on 2003年12月02日 10時37分 (#445814)
    Linuxカーネルの間違いでしょうか?
  • by Anonymous Coward on 2003年12月02日 11時39分 (#445882)
    「Debianでは2.4.18-14で修正されている」そうですが、となるとdebian の web site では debian謹製カーネルを使っていない、ってことなんでしょうか?
    • 自分達で作って使ってる以上、謹製じゃないのってかんがえられないんじゃ。
      --
      # rm -rf ./.
      親コメント
    • by Anonymous Coward
      リンク先を見れば判りますが、2.4.18-14は今日出たのですよ。
      Mon, 1 Dec 2003 21:17:12 +0100
      • by Anonymous Coward
        さっきapt-get updateしてみたけど、
        kernel-image-2.4.18-1-686_2.4.18-12_i386.deb
        が最新で、2.4.18-1-14にはなっていなかったみたいだけど。。。
        ソースは
        kernel-source-2.4.18_2.4.18-14_all.deb
        ですが・・。
        これでよいのでしょうか。
        • For Debian it has been fixed in version
          2.4.18-12 of the kernel source packages, version 2.4.18-14 of the i386 kernel images and ...

          下のパッケージの一覧と比較すると、
          この部分のバージョンの番号が source と i386 package の間でひっくりかえっているような気がするのですが。
  • by Anonymous Coward on 2003年12月02日 13時58分 (#446000)

    2.2系については,今回は問題なしということでよろしいのでしょうか?

    カーネルソースの当該箇所(mm/mmap.c)は,2.4系とは異なる実装であり オーバーフローのチェックもしているようです。

typodupeerror

「毎々お世話になっております。仕様書を頂きたく。」「拝承」 -- ある会社の日常

読み込み中...