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

rsync 2.5.6 にバッファオーバーフローの脆弱性 22

ストーリー by yoosee
秘密の裏口 部門より

yosshy 曰く、 "rsync のトップページに、rsync 2.5.6 に発見されたバッファオーバーフローの脆弱性がアナウンスされている。このセキュリティホールを利用するとリモートからコードを実行できるとの事。バグフィックス版の 2.5.7 がリリースされている。"

この脆弱性の影響を受けるのは rsync を server として使っている場合のみ (this vulnerability only affects the use of rsync as a "rsync server".)。自分のサーバで rsyncd が動いているかどうかは、netstat 等で TCP port 873 番を listen しているかどうかで確かめられる。 Gentoo の乗っ取りrsyncd が原因だったようだ。 また、この脆弱性でマシンに侵入され、先の linux kernel の脆弱性 で乗っ取りを受けるケースがあるので注意。さて、修正内容の rsync-2.5.6-2.5.7.diff.gz も見てみると... あらら、これ rsync だけの問題で終わるのかしらん?
この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • 何これ? (スコア:2, 参考になる)

    by yosshy (3545) on 2003年12月05日 0時35分 (#448449) 日記
    あらら、これ rsync だけの問題で終わるのかしらん?
    改めてパッチを見たところ、メモリ割り当て関連コードが、
    • malloc() → new(バイト数)
    • malloc() → new_array(型, 配列数)
    • Realloc() → realloc_array(ポインタ, 型, 配列数)
    で全て書き直されていますね(C++ か何かの影響?)
    また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。GNU libc に問題があるのでしょうか?
    • Re:何これ? (スコア:2, 興味深い)

      by Yoh2 (6924) <yoh2@d2.dion.ne.jp> on 2003年12月05日 1時12分 (#448468) 日記
      メモリ割り当て関数コードの追加は、使い勝手をよくするためのものでしょう。バグフィックスついでに従来の割り当てコードも書き直してしまえ、といったところではないでしょうか。

      また、メモリの割り当て最大サイズが 1GB に制限されています(こちらは DoS 対策か)。
      これは
      +#define MALLOC_MAX 0x40000000
      と、_new_array_realloc_array
      + if (num >= MALLOC_MAX/size)
      + return NULL; (これは2ヶ所)
      の部分のことですか?。これは単なる桁あふれ対策に見えますが。 32ビットに固定しているのは楽をするためでしょうか。
      # ちなみに1Gじゃなくて10Gですね。
      ……と思ったんですが、桁あふれ対策なら0x7FFFFFFFにしますね。(0xFFFFFFFFではないのは、size_tが符号つきの場合のことを考えてのこと)
      ん~、やっぱり謎だ。
      --
      巧妙に潜伏したバグは心霊現象と区別が付かない。
      親コメント
      • Re:何これ? (スコア:2, すばらしい洞察)

        by tt (2867) on 2003年12月05日 2時03分 (#448499) 日記
        ぱっとみーしかしてないんで外してそうですが、

        batch_flist->malloced *= 2;

        してメモリ再確保とかしているので、

        1. 最初にメモリ確保する部分でinteger overflowが起きてた
        2. そこだけ修正してOkだぜ、と思ったらやっぱり落ちる
        3. うは、*2 して realloc してるよ。最大確保可能量を1ビット減らそう
        4. 良く考えたら realloc するところも今回作った新しいメモリ確保の関数で確保するように変えればいいんだ

        というかんじでリリースしたのかなあと…

        まあ安全側に振る分にはいいかもしれないんですが、どちらかというとこういうところで0x7FFFFFFFとか0x40000000とかいった数字をじかに書いてるのが心配だったり…

        あと、0x40000000Byteは1GB(あるいは1GiB)だと思う。

        --
        -- Takehiro TOMINAGA // may the source be with you!
        親コメント
        • 0x40000000が10GBだとか、size_tが符号付きかもしれないだとか、だいぶ寝ぼけたことを書いてしまいました。失礼。

          size_tが最低32ビット(longの最低保証されるされるサイズ)はあると仮定するのは問題ないと思ってましたが、今調べたら、符号なし整数としか定義されていないんですね。迂闊でした。
          ということは、size_tのサイズが8ビット(shortの最低保証されるサイズ、16ビットより小さかったりしますが、charも整数に変わりはありませんし)な処理系があってもいいわけですね。最大255バイトしか確保できないmallocなんてヤですが。

          ということは、size_tのサイズを調べて、それが表現できる最大の整数を調べるのが正しい道ですかね。
          もっとも、rsyncを動かすような環境用の処理系なら、size_tのサイズが32ビット以上だと仮定しても問題ないとは思います。(←その発想が危険か……)

          この辺、パッチを書いた方も同じような誤解をしているんでしょうかね。

          -- 理解が不十分なことや推測をたれ流してしまったので、偉い人降臨ぷりーず
          --
          巧妙に潜伏したバグは心霊現象と区別が付かない。
          親コメント
          • by Anonymous Coward on 2003年12月05日 12時21分 (#448686)
            理想的な修正は、configureSIZE_MAX の存在・SIZE_T_MAX の存在・sizeof(size_t) のチェックをして、その結果を使うことなんでしょうが、「フィックスを早急にリリースする必要があり、configure のテストまでする余裕がない」「rsync の動作環境で size_t が32ビット以下はありえない」という状況なら、十分な修正であると思います。
            親コメント
    • by Anonymous Coward
      うむ・・・嫌な予感が・・・。
  • by Anonymous Coward on 2003年12月05日 0時58分 (#448462)
    恥を承知で。

    > あらら、これ rsync だけの問題で終わるのかしらん?

    って言われても、パッチのコードがさっぱり読めん俺には何がまずいのかが分からんのですけど。
    rsyncだけの問題で終わらんのですか?理由は?何で書かないの?

    rsync使ってるんだけど 873 番はlistenしてないみたい。
    本当かな。ものすげえ自信無いんでサーバ毎落としてるんだけど。
    # 個人サーバだから出来る芸当だな....
    • Re:分からん (スコア:2, すばらしい洞察)

      by Anonymous Coward on 2003年12月05日 1時06分 (#448467)

      ぱっとパッチを見た感じでは、ある構造体の配列を確保するときに、sizeof(ほげ) * n の計算でオーバーフローして、実際にはごく小さなメモリしか確保できてないことがある、っていう問題のようですね。

      とくに目新しい種類のミスではないです。煽りたかっただけでしょう。

      親コメント
      • by kei100 (5854) on 2003年12月05日 1時40分 (#448482)
        門外漢(開発とかしてない人間)なんでこう言うのもアレなんですが。

        >とくに目新しい種類のミスではないです。
        >煽りたかっただけでしょう。

        逆にそういうミスが見つからずに、
        今まで存在していたのが問題になる気がします。
        「チェック体制は大丈夫だったのか?」とかね。

        # 同じ過ちやミスは繰り返される物だと思うので、自戒を込めてID
        ## もちろん、無くす努力しろよ>自分
        --
        私を信じないで、貴方を裏切ってしまうから。
        親コメント
        • Re:逆に言えば。 (スコア:0, すばらしい洞察)

          by Anonymous Coward
          >逆にそういうミスが見つからずに、
          >今まで存在していたのが問題になる気がします。
          >「チェック体制は大丈夫だったのか?」とかね。

          なにをおっしゃるやら。ご自身でsignatureに書いてるじゃないですか。「誰も信じちゃい
          • by Anonymous Coward
            まぁ、
            「信用して使えるものがなにもない」という大問題を除けば、
            他に問題は無いでしょうけど……
      • by Anonymous Coward
        違います。
        オーバーフロー自体はありきたりですが、ここで問題視されてるのは原因ではなく対処の方。
        はい読み直し
    • by Anonymous Coward
      > rsync使ってるんだけど 873 番はlistenしてないみたい。
      > 本当かな。ものすげえ自信無いんでサーバ毎落としてるんだけど。
      > # 個人サーバだから出来る芸当だな....

      勉強しる。
      もし RedHat や OS X でお気楽サーバなんだったらもっとストイックな
      • by Anonymous Coward
        まあ実際Debianなんだけどもさ。
        --daemonモードの話だったのね。使ってないです、そんなもん。
        一応安心したので元に戻しました。

        そういうわけでDebianの方もfix出てます。まだDebianセキュリティ情報 [debian.org]には出てないみたいだけども。

        --
        rsync (2.5.5-0.2) stable-security; urgency=high

            * Non-maintainer release by the Security Team
            * Fixes remote exploitable heap overflow vulnerability
            * Applied patch from
    • by Anonymous Coward
      yoosee日記 [srad.jp]でフォローしてたのか....そんな所まで見に行かんっつー。

      という訳で詳しい人おねがい。
      • Re:分からん (スコア:2, すばらしい洞察)

        by Anonymous Coward on 2003年12月05日 12時15分 (#448679)
        疑問があるんなら記事本文に書かずにコメントで聞けてよバカ、って感じ。Linux の malloc() 系の関数に問題があるという話ではまったくないです。
        親コメント
        • by yoosee (196) on 2003年12月05日 13時17分 (#448748) ホームページ 日記
          う、その通りですね。載せ方を明らかに間違ったと思います。
          本文に書くにしても煽りっぽい書き方をする必要はないですね…。失礼しました。

          > Linux の malloc() 系の関数に問題があるという話ではまったくないです。

          ふーむ、単に場当たり的(と言っても必要十分)な対処をしただけ、ってことですか。
          なんで MALLOC_MAX を (1GB程度の) 定数値で入る必要があるのかが気になったのと、realloc で !ptr をわざわざ見てるのが何故かと思ったんですが、コードの他の部分でそういう危なさげな状況が起こり得るのでその回避なのかな。
          親コメント
          • Re:分からん (スコア:1, 参考になる)

            by Anonymous Coward on 2003年12月05日 19時22分 (#449024)
            >realloc で !ptr をわざわざ見てるのが何故かと思ったんですが

            reallocじゃなくてrealloc_arrayですね?
            単にreallocとの互換性のためでしょ。
            reallocはヌルポインタ渡されたらmallocと同じ動作をする事になっているので。

            親コメント
  • by Anonymous Coward on 2003年12月05日 3時45分 (#448531)
    librsync [sourceforge.net]は大丈夫なのか? duplicity [nongnu.org]などで使われているけど。
    #って、duplicityをホストしてるのって、クラックされたSavannahじゃん。(^^;;
  • by Anonymous Coward on 2003年12月06日 2時07分 (#449175)
    rsyncの穴を見付けた(どこを狙おうか?)
    ->rsyncといえばgentoo
    ->gentooを攻撃

    rsync使ってるのでac
typodupeerror

クラックを法規制強化で止められると思ってる奴は頭がおかしい -- あるアレゲ人

読み込み中...